Ivan Pozdeev <ivan_pozd...@mail.ru> added the comment: On 02.03.2019 9:01, Barry A. Warsaw
In all the cases you've described, Python is no different from any other Linux software. E.g. I can install something into /etc/profile.d that would break the shell or set an envvar that would change the behavior of standard utilities. This is by design: Linux is designed for maximum interoperability, so there's only one of each component in the system and everything uses it whenever it needs that kind of functionality. It does support multiple versions of the same software, but it's a compromise that significantly complicates maintenance (primarily how to disambiguate them when something requests just "component X"), so they strive to avoid it whenever possible. Likewise, complete freedom for root to wreak havoc in the system is also by design: distro maintainers only test and support official packages; anything else you use is either your responsibility or an app supplier's if they provide official support (and are within their right to deny support if you tweak the environment beyond their support promise) -- same as for any other software as well. This is not even specific to .pth files, either, so you won't really eliminate the problem by removing them. You can break any other part of Python in subtle ways just as well -- e.g. overwrite or override binary files with incompatible ones, causing segfaults in random places (https://stackoverflow.com/q/51816639/648265 ). Now, Linux does have "lower tier environments" that don't automatically affect "higher tiers". 1) Software installed into /usr/local doesn't hijack system scripts thanks to absolute paths in their shebangs; software in /opt is not on PATH at all; 2) /etc/profile* and bashrc are only executed by login shells and interactive shells, not by scripts, limiting their effect to processes created within a user session; 3) anything within a user's profile or run as a regular user (including ~/.bash*) doesn't affect system-wide settings and processes run as root. Blindly replicating 2) won't do for Python, however. Unlike Bash which has all the functionality compiled in, Python has an external standard library and arbitrary additional packages. They both are essential for its operation as a system component that other software can use without additional manipulations, AND Python gives the user freedom on how to arrange them in the system. So there must be a way to provide any "additional manipulations" that may be needed that the built-in startup logic doesn't have. From administration POV, any such startup logic is a part of the core offer to the system: core files+libraries+connecting logic = Python system component, so it must be invoked whenever Python is invoked. And we do already have ways to apply startup code only to a "lower-tier environment" if such a need arises: user-specific -- user site; interactive-specific -- PYTHONSTARTUP. There's no such thing as a "login shell" for Python but there's Python run in a user session; /etc/profile* can set envvars that would apply only there. So it seems to me that what you are asking for is "/etc/profile.d for Python". When designing such a feature, note, however, that the concept of login sessions is completely alien to Python. I believe a way to provide an additional site-packages directory will do (I can't readily see an already available way to do so in https://docs.python.org/3/using/cmdline.html ). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33944> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com