Message336984
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! |
|
Date |
User |
Action |
Args |
2019-03-02 03:59:43 | __Vano | set | recipients:
+ __Vano, mhammond, barry, brett.cannon, terry.reedy, jaraco, ncoghlan, pitrou, eric.smith, christian.heimes, ionelmc, SilentGhost, eric.snow, takluyver, steve.dower, veky, Ivan.Pozdeev, Anthony Sottile, ethan smith, cheryl.sabella, Chris Billington, Peter L3 |
2019-03-02 03:59:43 | __Vano | link | issue33944 messages |
2019-03-02 03:59:42 | __Vano | create | |
|