I’m gonna use this to sneak in a possibly-paraphrased quote that I really like (I first heard it from a John Green):
Long term systemic problems require long term systemic solutions.
This is tackling a UX/correctness problem that has calcified over a long time. I promise I’m not trying to hurry this along in a disruptive manner.
FWIW, I think it’s sensible for redistributions to disable user installs with
site.ENABLE_USER_SITE being modified (it supports a default of
False, instead of the regular
None). I don’t recall if we stated that in the PEP as a recommendation.
These together would basically mean that the system-provided Python can only be managed with a system package manager and all other install-via-pip use cases are delegated to virtual environments.
I guess one thing we could do to ease transitions is enable externally managed environments to present warnings and continue, instead of just erroring out, by supporting a Warning key in addition to Error. I’m unsure how useful that would be TBH, but doesn’t hurt to throw the idea out there.
Right now, this PEP says that we will basically disallow installing in both local and system, if the marker file exists.
Broadly, this PEP isn’t trying to solve the /usr vs /usr/local problem (that’s a sysconfig design problem to be solved separately). It’s trying to remove any possibility for users to break their system-package-manager-managed environment by adding/modifying/removing arbitrary files using (a new-enough) pip.
Another way to think of this: this gives redistributors the ability to tell Python tooling “hey, don’t meddle with files in /usr based schemes” (which… as noted affects /usr/local).
That said, part of the motivation behind suggesting setting the schemes explicitly and separately (at least, as far as I remember) was to make it easier to support the sysconfig changes and to eventually have better support the /usr vs /usr/local situation via a CLI argument in pip in the future. It could enable a hypothetical
pip install --scheme=posix_local/posix_global to modify files there (which could imply ignoring externally-managed, or require an extra flag). I’m imagining that a future functional change to sysconfig would implement the posix_local as a default (or simplify implementing/patching it) and make some other changes to actually properly support this.
--prefix approach is a neat idea, however (without patches) regular/vanilla pip installs already use
/usr as userbase and
posix_prefix as the scheme.