On Mar 1, 2019, at 19:59, Ivan Pozdeev <report@bugs.python.org> wrote:
> 
> Ivan Pozdeev <ivan_pozdeev@mail.ru> added the comment:
> 
> On 02.03.2019 2:25, Barry A. Warsaw wrote:
>> The fact that .pth files are global and affect the entire Python installation. <...> Right now, there’s no control over the scope of such environmental customizations; it’s all or nothing.
> 
> That's the entire purpose of "customizing the environment in which the
> program specified by the user would run". A customization can very well
> be implemented to be application-specific but it doesn't have to. Python
> was never designed to isolate modules from each other (an "application"
> as you say it is just another module) -- on the contrary, the amount of
> power it gives the user over the code that they don't control is one of
> its key appeals. A Python installation acts as a unit where anything can
> affect anything else, and the order is maintained with
> https://en.wikipedia.org/wiki/Soft_security .

So I just come at it from a different angle (I think Steve and I are aligned).

Here’s a very real use case about the dangers.  I use my Linux package manager to install a bunch of applications (I don’t totally agree with the “an application is just another package”).  I don’t even know that they are Python applications, they’re just tools that do something I like.  Now I have an idea for some cool Python thing to hack on and I just install a few development libraries with my package manager.   Maybe those libraries come from a secondary repo that has a different level of scrutiny.  Or maybe I think, hey what’s the harm to just `sudo pip install` a few things (yes, people do this all the time ;).

Subtly, under the hood, one of those transient dependencies down the stack installs some .pth file that executes some arbitrary code and breaks some of those distro provided applications.  And lets say I don’t notice weird things happening for a week.  Now I think “whoa! how did that application break? I didn’t change it at all”.  Not only did I mysteriously break things I relied on, but unless I’m an expert Pythonista and I know how to debug site.py, I’ve got almost no hope of fixing the problem by myself (SO to the rescue?).  If I do manage to diagnose the problem, I’ll have to go and uninstall the bad package, and I *should* report things to my distro or upstream.  Of course, upstream may say that it’s critical functionality to their library so too bad for you.

I’m not even making that up. :)

Sure, maybe the very concept of a distro-wide Python application is a mistake, but it’s what we have now, and it’s not going away.

>> 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).
> Right on the contrary. To decide what environment an application shall
> be run in is the user's prerogative. The application itself has
> absolutely no business meddling in this.

Again, I just look at this from a different perspective.  The user probably doesn’t even know all the environmental factors that affect the operation of their applications, and changes in that environment can happen without the user’s knowledge.  All they’re going to know is that application X which is critical to their work has just broken.  Sadly, the engineer looking into the bug they filed on it will not be able to reproduce the problem.  And now nobody is happy. :)

> With "individual packages", it's actually completely the same: the app
> can decide which ones it wants to use, but it's the user who decides
> which ones are available for use!

It’s actually not the same, and that’s the point.  An application won’t ever import a library that actively harms it.  But it has no such guards against changes to the environment — any environment, including magical Python code.