@RomanOnARiver So here's the thing: don't assume that any time you're asked to do something differently it's a change for the worse. (see also https://xkcd.com/1172/) You didn't say what pip is actually saying when it yells at you, but if it's the thing that most often generates these kinds of complaints - the "externally managed environment" warning message - you were doing it wrong all along, and pip just never told you before.

The new way is to use a virtual environment for each situation where you need to install things. There are many ways to create and manage virtual environments - the simplest being `python -m venv <path>` - and once you have one, you can use pip to install your packages in that environment, e.g. with `<path>/bin/python -m pip install wxPython`. (Or `<path>/bin/pip install wxPython` probably works too, but there are some weird niche cases where that runs into trouble.)

#Python

@RomanOnARiver Missed this one, sorry: honestly, the path can be anything you want, but I think the most common convention is to use a directory called `.venv` or `venv` inside the project directory for whatever project you're working on. If it's a project that has a directory. For a one-off script, people do all sorts of things, and again you can put it wherever you want, but one common choice is to use `<name-of-script>-venv` in the same directory where the script is.

There are some tools that manage virtual environments for you by storing them in either the same directory as your code or in a common directory somewhere in your user account's home. For example, pipenv, pip-run, pipx, and others. You might want to investigate some of these tools if you get tired of manually creating virtual environments for things.

#Python

@RomanOnARiver yup pipx is one of the more useful ones in my opinion. It lets you install Python applications - runnable programs like twine or pylint or so on - by just typing `pipx install <program>`, in most cases, and it will do the work of figuring out where to create a virtual environment and what to install in it, installing the package you requested, and making the executable scripts from that package available in your PATH.

#Python

@RomanOnARiver I don't know about wx specifically - I haven't used it - but if it has a runnable program in it, yeah, you can install it with pipx. (And if it doesn't have a runnable program in it, you can still try, but pipx will give you an error saying there was no script to install.)

BTW "wheels" are the standard way Python packages are distributed these days. (They're really just ZIP files with some constraints on their name and content.) So almost every time you run `pip install <package>` or `pipx install <package>` or similar with any pip-compatible tool, what it's doing behind the scenes is downloading a wheel file and unpacking it inside the virtual environment directory.

#Python

@RomanOnARiver Yeah probably. Although when a Python package depends on non-Python packages, as wx does here, things can get a little complicated - sometimes you have to install some system package with apt before it will let you install the Python package with pip/pipx/whatever.

As a rule, anything you install with pip/pipx/whatever is allowed to depend on stuff you've installed with apt, but never the other way around. (Which should probably never come up, since when you install an apt package, apt will take care of installing its dependencies, but maybe just something to keep in mind....)

@diazona ah I see they have a whole fun list https://github.com/wxWidgets/Phoenix#prerequisites

Edit: which of course is out of date. I don't remember installing anything extra in the past but maybe these are things I just had installed through other stuff