Ivan Pozdeev <ivan_pozd...@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, 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! ---------- _______________________________________ 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
