On 26 April 2017 at 19:19, Michal Cyprian <[email protected]> wrote: > 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. > > I would like to ask which solution would work for your applications > better, and what is in your opinion the right way to go.
From my perspective, the main goal of the change is to make it possible to fully recover from "sudo pip install <package>" by doing "sudo pip uninstall <package>", and the approach Debian took is sufficient to achieve that in almost all cases. So +1 from me for replicating something similar to Debian's approach in Fedora rather than blazing new trails by fiddling with `sys.prefix` directly. For the latter concern with CMake/autotools/Scons/etc, anyone doing local builds of C/C++ applications already needs to be careful not to be interfere with system packages, so I'm comfortable leaving that in the category where running C/C++ build system install commands outside a package build process without due care and attention is a generally bad idea (e.g. a "sudo make altinstall" of the Python 3.5 maintenance branch will clobber the system Python binaries in F25, and a "sudo make install" from the main Python development branch will mess with the default symlinks if you didn't set a suitable `/opt/` prefix). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia _______________________________________________ python-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
