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, if you need a compartmentalized application, a regular Python 
installation is a wrong tool for the job.
Compartmentalization comes at the price of:

  * rampant code duplication ('cuz if you actively distrust external
    code, you have to bring all the code you need with you) and all its
    corollaries (no automatic security fixes and modernized semantics;
    no memory and disk space economy from shared library reuse)
      o so compartmentalization is absolutely impossible within a shared
        environment: anything that you use can be changed by the user
        (e.g. to satisfy the requirements of something else, too)
  * lack of interoperability (how many Android apps do you know that can
    use each other's functionality?).

Venv does a pretty good job of providing you with a private copy of any 
3rd-party modules you require but not the envvars, the interpreter and 
the standard library (and any OS facilities they depend on). If you 
require a harder barrier between your app and the rest of the system 
and/or wish to actively prevent users from altering your application, 
you'll have to use a private Python installation (e.g. in /opt), or hide 
it from everyone with the likes of Pyinstaller, or an OS-level 
container, or a VM... or just drop the pretense and go SaaS(S) (that'll 
teach those sneaky bastards to mess with my code!).

> 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. All it can do is declare some 
requirements for the environment (either explicitly or implicitly by 
making assumptions) and refuse to work or malfunction if they are not 
met (and the user is still fully within their right to say: "screw you, 
I know what I am doing" -- and fool the app into thinking they are met 
and assume responsibility for any breakages).

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!