Python: Please stop screwing over Linux distros

Virtualenvs don't require using unfiltered/unsupervised/untrusted sources. They're a place to install things into, not a place to get things from.

The specific model that distros could adopt, if we went this route, is that each Python package builds into a .whl, they're build-dependencies of applications, and applications install .whls into a virtualenv at build time. You'd still restrict packages to come from the distro with the usual policies (built from source code, compliant with licensing, not contacting the network at build time, etc. etc.).

So, for instance, installing "python-somelib" would get you a /usr/share/python-wheels/somelib-1.0.whl, built from source. The build process of "someapp" would create a /usr/share/someapp/venv, pip install that wheel into that virtualenv, and then symlink /usr/bin/someapp to /usr/share/someapp/venv/bin/someapp.

The PEP goes into more details about why virtualenvs are recommended, and I can give you a whole host of subtle reasons, but that's not really the point - the point is that it's defensible, not that it's perfect, and that it's very easy to implement with what works today. So if you ask the PSF to come up with something that magically solves the problems and makes people sad if necessary, this is literally what they're going to come up with. If you don't like that outcome (and there are good reasons not to like it!), then you shouldn't ask for them to arbitrarily pick an outcome some people won't like.

> Create virtualenv with the Python version you want (including pypy!) and do your pip thing there

You might benefit from using Pipx in this case: https://pypa.github.io/pipx/

Pipx is good for the case of "I want to run a standalone Python application that is available through Pip, but not my system's package repo." This is a more common case than you might think.

It's a sensible alternative to `pip install --user`, and having self-contained deps for tool is a bit like `npm install --global` or even `volta install`.

Users generally don't want Python packages; they want software. They don't care what it's written in, and shouldn't have to install it differently depending on what you chose.

“Just learn $language_package_manager_of_the_day, and hope it doesn't break anything when your system changes” is the equivalent of the 90s “./configure ; make ; make install”, and we should have moved past that for end-users by now. Most users are not developers, and installation procedures need to cater to both.

My usual approach is to let the distro install the packages it wants and then, for each thing I'm working on (I sometimes write Python code for a living) can have a separate environment with different module versions. This makes sense when my artifacts are deployed via Docker images that are generated with `pip install`, but not as much if you plan to install them in your machine. The only thing I build like this for public consumption is pip-chill, which is not intended to be used with the bare Python environment of the distro (I probably should add something that makes it refuse to install that way).

Even when the things are not Python-based, I often use a virtual environment, managed with virtualenvwrapper (installed on the distro level). One example is a Terraform config that relies on some Python tools to manage deployments - the Python tools are local to that virtual environment and not usable anywhere else.

If I need to develop something that'll need to run with the distro directly (something that could be distributed as ditro packages) I'd use a virtual environment and tailor the package versions in requirements to the ones available in the distro. This way, multiple distros can be addressed with multiple environments pointing to the same source directory and multiple requirements files for tests.

The problem here is that distros only supply one version of the package which means you gain nothing by having that same version installed in multiple virtualenvs.

So I guess the problem actually lies in the python library ecosystem that's becoming a npm like dependency hell.

The relevant question here is probably whether the library ecosystem is like that because the packaging tooling sucks or is it the other way around?