Description of problem: If you need to install a Python module globally that isn't available in Fedora, the easiest way to do so is with pip. However, that module then fails to be available to programs that want to play it safe and disable the users' site directories. Version-Release number of selected component (if applicable): python3-3.12.0-1.fc39.x86_64 How reproducible: 100% Steps to Reproduce: 1. sudo pip install pyasyncore 2. python3 -s -c 'import asyncore' Actual results: ModuleNotFoundError: No module named 'asyncore' Expected results: Import works. Additional info: This was implemented here: https://fedoraproject.org/wiki/Changes/Making_sudo_pip_safe However, the description mostly mentions -I there, which is a stronger flag than -s (which is briefly mentioned, though). I can sympathise with the reasoning for this change, but I think it is overly harsh to group manually *system administrator* installed modules, with user modules. Currently, there is no clean way to respect what the system administrator has installed, but ignore individual users' changes.
Note that this also affects RHEL. This bug should probably be cloned.
What you describe is exactly the intended behavior. What are you trying to achieve and why do you need to "install a Python module globally"? If you wish to propose a new approach that Fedora should take, I invite you to do so via the Fedora's Python mailing list: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org/ > Note that this also affects RHEL. Yes. And even if we design a new alternate solution for Fedora, it's unlikely to make it to existing RHEL versions.
The scenario is that my users need a third-party application, so I want to install that globally on the system for everyone to access. However, that application requires a Python module not packaged by Fedora. Let's call it pyfoobar. Fortunately, it's available in pypi, so I can make sure it's available by simply running "sudo pip install pyfoobar". However, the application tries to be robust, so it runs everything via "python3 -s". That way, custom user changes are less likely to interfere with anything. On a standard Python this works fine, but not on Red Hat systems because of the mentioned patch. The way I see it, there are (at least) three trust levels: a) Everyone is trusted b) The sysadmin is trusted, but not the users c) Only Fedora/Red Hat is trusted Standard python without any flags operates under a). I can fully understand that you'd like platform-python to run under model c). The problem is that as a sysadmin, I'd generally like model b). Right now, I don't see how I can do that without breaking your improvement and putting pip stuff in the normal site dir. :/ My suggestion would be to tweak the patch so that it triggers on a more restrictive flag than -s. E.g. just for -I, or for -P. Hmm... I see that platform-python seems to be gone. Is there even a user of this patch any more? Perhaps it can simply be removed?
This message is a reminder that Fedora Linux 39 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 39 on 2024-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '39'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 39 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
An attempt to start a discussion: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org/thread/5WWXQTQ7GUZ2FVTPHA67RN5X2T65DDV2/
This bug appears to have been reported against 'rawhide' during the Fedora Linux 42 development cycle. Changing version to 42.