On Thu, Apr 27, 2017 at 11:48:06PM +1000, Nick Coghlan wrote: > On 27 April 2017 at 23:04, Daniel P. Berrange <berrange@xxxxxxxxxx> wrote: > > On Thu, Apr 27, 2017 at 04:32:09PM +1000, Nick Coghlan wrote: > >> 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. > > Aye, /usr/local/lib has priority: > > $ docker run --rm ncoghlan/debian-python python3 -m site > sys.path = [ > '/', > '/usr/lib/python3.4', > '/usr/lib/python3.4/plat-x86_64-linux-gnu', > '/usr/lib/python3.4/lib-dynload', > '/usr/local/lib/python3.4/dist-packages', > '/usr/lib/python3/dist-packages', > ] > USER_BASE: '/root/.local' (doesn't exist) > USER_SITE: '/root/.local/lib/python3.4/site-packages' (doesn't exist) > ENABLE_USER_SITE: True > > User level package installs take priority over system level ones > (regardless of distro), so the current container build use case for > root level pip installations can typically be met equally well by > running as a non-root user inside the container and doing "pip install > --user ...". Unfortunately, as with the venv option, there are a *lot* > of container build scripts out there that don't do that :( It would be nice if openstack devstack didn't install anything with sudo and instead kept it all isolated as a user, but I don't see such a change happening. So anything we can do to reduce the damage of "sudo pip" is welcome, particularly if it aligns with what Debian already do. 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
