On 2/24/2021 4:26 PM, Christian Heimes wrote:
On 24/02/2021 15.16, Random832 wrote:
On Wed, Feb 24, 2021, at 06:27, Christian Heimes wrote:
Separate directories don't prevent clashes and system breakage. But they
provide an easy way to *recover* from a broken system.

I think it could be turned into a way to prevent them by A) having 
site-packages always take precedence over dist-packages [i believe this is 
already the case] in normal usage and B) providing an option to the 
interpreter, used by system scripts, to exclude site-packages entirely from the 
path.

Basically, site-packages would effectively be layered on top of "Lib + dist-packages" in a similar way to how 
a venv is layered on top of the main python installation - the inverse of the suggestion someone else in the thread 
made for the system python to be a venv. This wouldn't *exactly* be a venv because it wouldn't imply the other things 
that entering a venv does such as "python" [and script names such as pip] being an alias for the correct 
version of python, but it would provide the same kind of one-way isolation, whereby the "system environment" 
can influence the "normal environment" and not vice-versa, in the same way that packages installed in the 
main installation affect a venv [unless system-site-packages is disabled] but the venv obviously has no effect on the 
main installation.

Yes, you are describing one major aspect of my idea for a system Python
interpreter. I'm happy to read that other users are coming to similar
conclusions. Instead of an option I'd create a new executable to lock
down additional things (e.g. isolated mode, code verification hook). A
separate executable would also allow distros to provide a stripped down
interpreter that does not cause bad user experience.

I mean, this is _precisely_ what PEP 370 defines (including the "-s" option and PYTHONNOUSERSITE env variable to provide that one-way isolation).

Is the problem that pip doesn't use it by default? Or that the distros went and made patches for the runtime rather than patching pip? (For Windows installs from the Store, where even admin rights can't do an all-users package install, I added a new config file location for pip to change this default, but a patch would also have worked.)

Maybe we need an easier way to patch the location of user site packages? I also had to do this for the Store install on Windows, and it's a little bit of a hack... but maybe having an official recommendation would help encourage distributors to use the mechanism?

Cheers,
Steve
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/IHEECOXYDPJ6ZQJE2QTGPDOOCOP7J37A/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to