On Mar 1, 2019, at 09:27, Ivan Pozdeev <report@bugs.python.org> wrote:

> Startup code (custom or not) is not a dependency of anything. It rather customizes the environment in which the program specified by the user would run, _before_ any user code could be allowed to get control. It is not a part of the program to be run but rather of the environment that the user wants, and it needs to be implicit so the user can use the same commands and code (compare venv). This is a required feature because the stock Python startup logic cannot possibly provide all the customizations that a user may need (compare initrd).
> 
> .pth's are equivalent to sitecustomize but allow the user to manage the set of code chunks automatically using the packaging infrastructure (compare .d directories in UNIX). The fact that this feature is mixed up with and often supplements "real packages" that a program would explicitly use is actually incidental: a package with a .pth does not need to have any functionality intended for explicit use.
> 
> We already identified a few real reasons: hard to see, hard to debug, encourages unreadable code, run in arbitrary order when the order matters (and IIRC I provided fixes for all). What else?

The fact that .pth files are global and affect the entire Python installation.  That’s not so bad in venvs where we have environmental isolation, but it’s really bad (IMHO) for the global Python interpreter.  Right now, there’s no control over the scope of such environmental customizations; it’s all or nothing.  Applications should be able to opt in or out of them, just like they can with individual packages (which must be imported in order to affect the interpreter state).  The trick then is how to define opt-in for applications *before* the interpreter gets to user code.