On Wed, Apr 26, 2017 at 7:13 AM, Charalampos Stratakis <cstratak@xxxxxxxxxx> wrote: > Forwarding to fedora-devel as well > > Charalampos Stratakis > Associate Software Engineer > Python Maintenance Team, Red Hat > > ----- Original Message ----- > From: "Michal Cyprian" <mcyprian@xxxxxxxxxx> > To: python-devel@xxxxxxxxxxxxxxxxxxxxxxx > Sent: Wednesday, April 26, 2017 11:19:00 AM > Subject: What is your opinion on "sudo pip" fix for Fedora 27? > > At the present time, running sudo pip3 in Fedora is not safe. > Pip shares its installation directory with dnf, can remove > dnf-managed files and generally break the Python 3 interpreter. This is true of every version of pip, not merely pip3. It was also true of CPAN, and of many gradle, maven, and ant working environments that semi-randomly collate the very latest versions of indeterminate components and spray them on top of your system workspace with their own quite distinct ideas about packaging and versioning. There is no solution to this problem, except to use tools like "pyvenv" to set aside secluded workspaces for Python modules and their dependencies assembly. So, for most developers, they *should not* use "sudo pip". They should remain in user space, or possibly in shared workspaces, to avoid overwriting system components. > Our first attempt to make sudo pip safe on Fedora [0] was > based on using a different binary (/usr/libexec/system-python) > for RPM packaging purposes and changing the behavior > of /usr/bin/python3 (and pip that uses its settings) to install > under /usr/local by default. Switching all the Python 3 packages Oh, Oh my. The extent to which this unworkable is... fascinating. You will inevitably install incompatible future versions of critical packages which are incompatible with the Fedora system packages. And as soon as you install one that breaks RPM, if /usr/local/ if ahead of /usr in your search path for modules, you are *screwed*. And if /usr/local is first, well, an RPM update may introduce a component that is incompatible with the pip installed modules at arbitrary times. > to system-python turned out to be much more problematic than > expected and we had to postpone the Change for F27. Sorry, no surprise there. > We decided to try a different approach. The main idea is to detect > an ongoing RPM build and modify the behavior of the Python 3 > executable only when in normal user environment so that RPM builds > won't be affected at all. See https://xkcd.com/1172/ . You're inventing a workflow that isn't supported by *anyone*. > The adjustment of the behavior can be done on different levels. > The first option is to set the sys.prefix variable to /usr/local > when the interpreter is initialized. This will affect > all the install methods, but the solution can cause some > problems in applications that rely on the value of sys.prefix. > A prototype of this implementation can be seen here [1]. I'm sorry, but.... ouch. Please stop trying to implement "pip install" as a system installation tool. The effort would be better spent upgrading and enhancing "py2pack". > The other possibility is to limit the pip install location change > to distutils and pip [2]. This is the "safer" option, but does > not cover all corner cases. For example, Python software built > locally using cmake or similar tools will be installed into > /usr/lib and can conflict with system tools. Debian chose to > implement similar solution. It's local environment specific, unstable software sensitive to arbitrary and unmanaged upstream dependency updates, and extremely sensitive to local system pip modules. It *does not belong* in /usr/lib. Because the components are modular and bundled in a non-RPM compatible fashion, it behooves developers to use a tool to segregate the tools as much as feasible from the Fedora underlying infrastructure. i.e., use pyvenv to build them in a contained environment segregated from the system files. > I would like to ask which solution would work for your applications > better, and what is in your opinion the right way to go. I will > appreciate any costructive comments or ideas on how to improve these > patches. If you want to check some specific use-case you can use the images > docker.io/mcyprian/sudo_pip_sys_prefix and > docker.io/mcyprian/sudo_pip_install_prefix > to try out the two mentioned implementations. > > [0] https://fedoraproject.org/wiki/Changes/Making_sudo_pip_safe?rd=User:Torsava/Making_sudo_pip_safe > [1] https://github.com/mcyprian/python3/commit/6077c96460c03ddc334bae654fffcce44eb6873d > [2] https://github.com/mcyprian/python3/commit/ac2f266a90871d67ba8d0b70d2b0ebe47732f064 > > Michal Cyprian > _______________________________________________ > python-devel mailing list -- python-devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to python-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
