On 27 April 2017 at 23:04, Daniel P. Berrange berrange@redhat.com 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 :(

Cheers, Nick.