[Bug 1228165] New: Position of SUSE Python interpreters on Externally managed environments
https://bugzilla.suse.com/show_bug.cgi?id=1228165 Bug ID: 1228165 Summary: Position of SUSE Python interpreters on Externally managed environments Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Python Assignee: python-maintainers@suse.com Reporter: mcepl@suse.com QA Contact: qa-bugs@suse.de CC: dmueller@suse.com Target Milestone: --- Found By: --- Blocker: --- https://packaging.python.org/en/latest/specifications/externally-managed-env... This linked specification presents the use case rather well. Unlimited installation of Python packages can cause a serious damage, when the system component imports incompatible version of Python package instead of the intended one. (A parallel thought: are there any initiatives to port low-level components like firewalld to compiled languages? I know about firewalld-recode [1], but it seems to be quite dead). This specification tries to alleviate the problem by making it more difficult and painfully obvious that installing packages outside of the using system package manager is a wrong idea. That might be a good idea for normal users, but it seems like quite a bother for people who create containers, where the designers of such systems usually know what they are doing and who can check and test that nothing has been broken. The purpose of this bug is to discuss, whether we could produce some better solution to the problem, which wouldn’t be that obnoxious to our customers. One possible improvement would be to change our default hashbang to include `-s` parameter to calling our Python interpreters, so that modules in `$HOME` are not considered. Any possible improvements? [1] https://web.archive.org/web/20160318144103/https://fedorahosted.org/firewall... -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228165 Daniel Garcia <daniel.garcia@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |daniel.garcia@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228165 https://bugzilla.suse.com/show_bug.cgi?id=1228165#c1 --- Comment #1 from Daniel Garcia <daniel.garcia@suse.com> --- (In reply to Matej Cepl from comment #0)
One possible improvement would be to change our default hashbang to include `-s` parameter to calling our Python interpreters, so that modules in `$HOME` are not considered.
Yes, I think we should add this to our python-rpm-macros so this will prevent possible issues in the future. But I'm not sure if forcing this everywhere could break some user cases, I'm thinking about python plugins installed as user with pip, but it's a very specific user case, so we should try and maybe provide a way to do not do that. And about this, I think that it's a good idea to do not implement in containers (for now), because developers are used to create containers just with the interpreter and install everything with pip and this change will break the typical user case for containers. Even when it's recommended to use virtualenvs, with containers it looks like a double sandboxing, and a lot of people won't use there, so the safer option is to do not do this in containers, at least until it's more spread across all the providers so everyone is used to it. Having the externally-managed by default isn't a big issue technically, because anyone can bypass using the "--break-system-packages" or removing the "/usr/lib64/python3.11/EXTERNALLY-MANAGED" file manually. But I can understand people fearing to use this option because it says that you will certainly break your system and know it, so it's like to say that I won't ask for support if something is wrong, even if it's exactly the same in the filesystem, the social implication of this is big enough to consider not deliver in containers until it's clear for everyone. As as side note, the current "default" python container [1] in dockerhub is based on Debian that has the externally managed file, but in this case, the python interpreter is installed isolated from the system one, in /usr/local, so in this case it's possible to use pip without any warning. [1] https://hub.docker.com/_/python/ -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228165 https://bugzilla.suse.com/show_bug.cgi?id=1228165#c2 --- Comment #2 from Matej Cepl <mcepl@suse.com> --- We can introduce a new option to the Python interpreter (let’s call it tentatively -t as a next letter to -s; the other option is -ss), which would ignore not only Python modules in ~/.local/lib/python*/site-packages, but also /usr/local/lib*/python*/site-packages. Then we can just not use EXTERNALLY_MANAGED at all. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228165 John Paul Adrian Glaubitz <adrian.glaubitz@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |adrian.glaubitz@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228165 Dominik Heidler <dheidler@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dheidler@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠suse.com