You signed in with another tab or window.
Reload
to refresh your session.
You signed out in another tab or window.
Reload
to refresh your session.
You switched accounts on another tab or window.
Reload
to refresh your session.
By clicking “Sign up for GitHub”, you agree to our
terms of service
and
privacy statement
. We’ll occasionally send you account related emails.
Already on GitHub?
Sign in
to your account
It should be possible for a Python environment to disable the "user site" functionality without patching the stdlib
#99312
It should be possible for a Python environment to disable the "user site" functionality without patching the stdlib
njsmith
opened this issue
Nov 10, 2022
· 4 comments
The
stdlib module
site.py
runs at startup, and is responsible for setting up a Python environment's basic search paths. There are various ways to customize this, e.g. you can drop in a
sitecustomize.py
file to add new search paths.
One thing
site.py
does by default is to add the "user site path" to
sys.path
, e.g.
$HOME/.local/lib/python$VERSION/site-packages
. This makes sense and is quite handy for global python installs where users want to add a few packages without the fuss of creating a venv: just
pip install --user somepkg
. And this is becoming more important as moves towards doing
--user
installs by default when outside a venv.
However, I think most people do
not
expect
pip install --user somepkg
will effectively inject
somepkg
into every venv that user ever creates. The whole point of creating a venv is to make an isolated environment. But, currently,
site.py
always
adds the user site path to
sys.path
if possible, and there's no way to configure this through an envvar or
sitecustomize.py
– the only way to permanently disable it is to manually patch
site.py
in the stdlib. (Specifically:
site.py
runs
addusersitepackages
before it runs
execsitecustomize
,
see here
.) This leads to surprising behavior, or
fragile hacks like modifying site.py with regexes
.
There should be some way to create a Python environment where the user site path is disabled, without modifying the stdlib. (And venv should probably use it.)
One option would be to move
execsitecustomize
earlier in the setup, before
addusersitepackages
, so it has the option of doing
import site; site.ENABLE_USER_SITE= False
. I think the main downside here is that right now, if someone has a
sitecustomize.py
file in their user site path, it will no longer be executed. This is ... kind of fine?
sitecustomize.py
is supposed to be reserved for the python environment itself; user-specific customization is supposed to go in
usercustomize.py
. So e.g. this kind of setup is already broken if a distro ships a Python with a custom
sitecustomize.py
in it – which Ubuntu, for example, already does! And if it's a major problem we could even detect this case and warn about it. (E.g. after
addusersitepackages
make a second check for the existence of
sitecustomize.py
.)
Alternatively we could add some other kind of configuration file,
earlysitecustomize.py
or whatever. As long as it's something that's (a) on disk, so it's persistent for a given environment, and (b) can be dropped into a venv.
Doh, I'm dumb. I missed
this bit of code
that already does
ENABLE_USER_SITE = False
whenever we have a
pyvenv.cfg
with
include-system-site-packages = false
. So this is already solved for venv, it's just hard-coded to only work with venvs, not any other kind of isolated envs like
conda
or
the thing I'm working on
.
not any other kind of isolated envs like
conda
Ah, so
this
is where that (very frustrating) user problem is always coming from...funny to see this come full circle.
The generic options are command-line param -s or env var PYTHONNOUSERSITE; are these suitable for you?
Neither of these appear to be a solution for either
@njsmith
's use cases or conda's (or indeed, other redistributors), at least without patching (i.e. essentially the previous approach) because that is user-set and -controlled configuration, whereas distributor-controlled config is needed.
The
stdlib module site.py
runs at startup, and is responsible for setting up a Python environment's basic search paths
FWIW, technically, this isn't quite true anymore (the site module runs, but it doesn't come from
site.py
), since
site.py
is deep-frozen at build time. I raised an issue for this in
#107344
.
In my case, disabling user site-packages is definitely one use case. I also want to be able to add other
site-package
directories. I don't really want to be using
sitecustomize
(though, perhaps that is what it is indeed for), and want to be able to do this on an already built distribution. I would be happy if I don't need to patch the stdlib to do this though.