On Thu, Apr 27, 2017 at 04:32:09PM +1000, Nick Coghlan wrote: > On 27 April 2017 at 11:47, Nico Kadel-Garcia <nkadel@xxxxxxxxx> wrote: > > On Wed, Apr 26, 2017 at 7:13 AM, Charalampos Stratakis > >> 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. > > Nothing is changing in terms of *recommended* practices. This change > proposal is entirely about harm mitigation for the cases where users > *do* run "sudo pip ...", either because that's their instinctive > reaction to a permissions error, or because some misguided > installation instructions for a 3rd party package advised them to do > it. FWIW, Openstack's devstack script will use "sudo pip" to install python bits required by openstack and thus often splatter any RPM managed versions of the same modules. > Debian and derivatives already mitigate the potential harm for these > cases by requiring the "--install-layout=deb" option to be passed to > get distutils to install into the system directories rather than doing > it by default: https://wiki.debian.org/Python#Deviations_from_upstream > > Their approach means that any harm caused by "sudo pip install X" can > subsequently be fully reversed by doing "sudo pip uninstall X". > > At this moment, this is NOT true for Fedora and derivatives. Instead, > the remediation step here is "sudo pip uninstall X && sudo dnf > reinstall <something>" where you have to: > > 1. Figure out what "<something>" needs to be > 2. Hope that whatever you broke didn't affect your ability to run > "sudo dnf reinstall" Yep, recovering the system python install to a pristine state after 'devstack' has done its stuff is very painful right now :-( devstack was originally written for Ubuntu systems, so I guess they don't suffer as much due to the Debian specific change you describe above. Which location takes priority in Debian if the same module is installed in both places ? The DPKG location, or the Pip location ? Presumably it would have to be the pip version that takes priority if you want it to be usable for updating the (likely older) distro provided versions. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
