Followup to commit 5c479d7a13.
In this case, PEP 668 was created to allow a thing that Debian wanted,
which is for `pip install foobar` to not break the system python. This
despite the fact that the system python is fine, unless you use sudo pip
which is discouraged for separate reasons, and it is in fact quite
natural to install additional packages to the user site-packages.
It isn't even the job of the operating system to decide whether the user
site-packages is broken, whether the operating system gets the answer
correct or not -- it is the job of the operating system to decide
whether the operating system is broken, and that can be solved by e.g.
enforcing a shebang policy for distribution-packaged software, which
distros like Fedora do, and mandating not only that python shebangs do
not contain `/usr/bin/env`, but that they *do* contain -s.
Anyway, this entire kerfuffle is mostly just a bit of pointless
interactive churn, but it bites pretty hard for our use case, which is a
container image, so instead of failing to run because of theoretical
conflicts with the base system (we specifically need base system
integration...) we fail to run because 5 minutes into pulling homebrew
updates at the very beginning, pip refuses point-blank to work. I
especially do not know why it is the job of the operating system to
throw errors intended for interactive users at people designing system
integration containers who cannot "break" the system python anyway as it
is thrown away after every use.
Fix this by doing what homebrew should have done from the beginning, and
opting containers out of this questionable feature entirely.
Eli Schwartz
a35d4d368a