[Python-Dev] Deprecate PEP 370 Per user site-packages directory?

[Toshio Kuratomi]

On Jan 13, 2018 9:08 AM, "Christian Heimes" <christian at python.org> wrote:

Hi,

PEP 370 [1] was my first PEP that got accepted. I created it exactly one
decade and two days ago for Python 2.6 and 3.0.


I didn't know I had you to thank for this!  Thanks Christian!  This is one
of the best features of the python software packaging ecosystem!  I almost
exclusively install into user site packages these days.  It lets me pull in
the latest version of software when I want it for everyday use and revert
to what my system shipped with if the updates break something.  It's let me
I install libraries ported to python3 before my distro got stopping to
packaging the updates.  It's let me perform an install when I want to test
my packages as my users might be using it without touching the system
dirs.  It's been a godsend!


Fast forward 10 years...

Nowadays Python has venv in the standard library. The user-specific
site-packages directory is no longer that useful. I would even say it's
causing more trouble than it's worth. For example it's common for system
script to use "#!/usr/bin/python3" shebang without -s or -I option.


With great power comes great responsibility...

Sure, installing something into user site packages can break system
scripts.  But it can also fix them.  I can recall breaking system scripts
twice by installing something into user site packages (both times, the
tracebacks rapidly lead me to the reason that the scripts were failing).
As a counter point to that I can recall *fixing* problems in system scripts
by installing newer libraries into site packages twice in the last two
months.  (I've also fixed system software by installing into user and then
modifying that version but I do that less frequently... Perhaps only a
couple times a year...)

Removing the user site packages also doesn't prevent people from making
local changes that break system scripts (removing the pre-configuration of
user site packages does not stop honoring usage of PYTHONPATH); it only
makes people work a little harder to place their overridden packages into a
location that python will find and leads to nonstandard locations for these
overrides. This will make it harder for people to troubleshoot the problems
other people may be having.  Instead of asking "do you have any libraries
in .local in your tracebacks?"  as an easy first troubleshooting step.
Without the user site packages standard we'll be back to trying to
determine which directories are official for the user's install and then
finding any local directories that their site may have defined for
overrides....

I propose to deprecate the feature and remove it in Python 4.0.


Although I don't like the idea of system scripts adding -s and -l because
it prevents me from fixing them for my own use by installing just a newer
or modified library into user site packages (similar to how c programs can
use overridden libraries via ld_library_path), it seems that if you want to
prevent users from choosing to use their own libraries with system scripts,
the right thing to do is to get changes to allow adding those to setuptools
and distutils.  Those flags will do a much more thorough job of preventing
this usage than removing user site packages can.

-Toshio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180113/584b0977/attachment.html>