On 1 May 2017 at 09:59, Nico Kadel-Garcia <nkadel@xxxxxxxxx> wrote: > Wouldn't it be more effective, more safe, and more efficient to > improve the existing support for doing "the right thing", rather than > trying to outsmart a build and deployment system that is essentially > outside your control? To encourage the use of "pyvenv" for local such > modules, in a local userspace, rather than as a default system > version? This is already happening, and is entirely independent of the discussion at hand (e.g. see [1], a presentation I did with Graham Dumpleton at Red Hat Summit/DevNation last year advocating for Red Hat's customers to adopt exactly this model). On Fedora's Developer Portal, virtual environments share the front page of the Python section with running Python itself: https://developer.fedoraproject.org/tech/languages/python/python-installation.html Responding to "We want to make running 'sudo pip install' less harmful and easier to recover from when people do it by mistake" with "We should discourage the use of 'sudo pip install'" remains an unproductive non sequitur - we *know* it's inherently fragile, and requires deep knowledge of both Python packaging and RPM packaging to do reliably. However, Red Hat can't (and won't) answer a commercial support call from a distressed customer with "Ooh, you shouldn't have done that - sucks to be you" (although these supportability problems *are* one of the reasons we only ship "pip" commercially through Software Collections, and not as part of the system Python runtime). Fortunately, we have the ability to influence *all* of the moving parts (upstream pip, upstream CPython, downstream distros) here, and help to incrementally adjust their respective default behaviours so that the key risks involved in running "sudo pip install" are comparable to those involved in running "curl $REMOTE_SCRIPT | sudo sh". If the intended benefit of this change remains unclear, it may help to focus on a specific concrete case, which would be that the following operations should be completely indistinguishable at the system level from not having done anything at all (except in the sudo logs): $ sudo pip3 install contextlib2 $ sudo pip3 uninstall contextlib2 At the moment, that's *not* the case if you had previously done "sudo dnf install python3-contextlib2", as both of the above commands will mess with the system contextlib2 packages. With the proposed changes, contextlib2 may behave unexpectedly while the non-system version is installed, but removing the pip installed version will be sufficient to restore the affected machine to its previous state. (I chose contextlib2 as the example here, rather than something more complex like ansible, as pip installing components with dependencies makes the cleanup process more complicated. However, the /usr/local/ split helps there as well, by making the installed-via-pip versions easier to identify even without checking the PEP 376 installation metadata) Cheers, Nick. [1] https://www.slideshare.net/ncoghlan_dev/developing-in-python-on-red-hat-platforms-devnation-2016 -- Nick Coghlan | ncoghlan@xxxxxxxxx | Brisbane, Australia _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
