Handling Externally Managed Environment Packages that are Outdated

[marsfan (Gabe)]

@aragilar

Make a venv and add it to $PATH would be the logical and simplest thing to do for tools like pip/pipx. pip should be upgradeable inside any venv it gets used in, and ensurepip can be used to bootstrap pip if that is needed.

That seems like a pretty good solution for this. Having a single main venv for all packages the packages (and incidentally solves the issue I mentioned before about large packages as well). But it raises the question: Why is that not the behavior that we take by default. Maybe Python/pip should automatically create a “user venv” instead of blocking installing packages with pip altogether? Wouldn’t that be a more streamlined way of handling things that preserves the distro-level packages, but also makes a more seamless transition from what user’s have done for years.

@ncoghlan

Where folks get themselves in trouble is when they’re running a server distro that is nearing (or even past) its End of Life date, and trying to use the provided pip directly, rather than just using it to bootstrap a newer pip with python3 -m pip install --ignore-installed --user pip, and then using that newer pip to install other components (bootstrapping a user level install of uv instead of a newer pip is also often a reasonable option these days).

The thing is, using that command still results in the “System Managed Installation” warning, so you still need to use the --break-system-packages flag, as you could technically still end up shadowing system packages in a breaking way (at least, according to this post)