It should be possible for a Python environment to disable the "user site" functionality without patching the stdlib

Lib/site.py の addusersitepackages と execsitecustomize 周辺の起動シーケンスから始め、次に venv が環境をどのように作成・設定するかを調べます。提案されている sitecustomize.py、usercustomize.py、および代替の設定アプローチを比較します。標準ライブラリにパッチを適用せずに、環境ごとにユーザー site パスを無効化でき、既存のカスタマイズと互換性のある動作をする永続的な方法が得られれば完了です。

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.