On 27 April 2017 at 19:34, Fabio Valentini <decathorpe@xxxxxxxxx> wrote: > If the "only" reason to change the current behavior is to prevent > users from nuking their systems (be it by accident, or by following > outdated instructions from the web), then why not prevent running > "sudo pip" at all? The main problem with that approach is that it breaks container build processes where there's a far more constrained sequence of operations than we see on a developer workstation or a traditional stateful server: - install a known set of system packages - install a known set of Python packages into the system Python - run a single known application directly in the system Python The immutability of the container image then protects the app developer from having to support arbitrary combinations - they only support the specific combination that *they* put together. It's still an unresolved design debate in the upstream Python community as to whether this is a bad idea or not - some folks advocate for always using virtual environments (even in single purpose containers), while others see the Python level virtual environment as being redundant when you already have the system level container providing isolation from other processes. So even though at the distro level we'd advise against doing that, I don't think it makes sense for us to go out of our way to break it when other options are available. Longer term, the upstream pip devs *would* like to get to a design closer to the npm one (where global installs are avoided by default and you have to supply an "I really want a system global installation" command line flag to override that), but they're not only up against the same backwards compatibility constraints that we are in terms of existing container and system package build processes, but also have to provide sensible behaviour on non-Linux systems (see [1] for the gory details). Cheers, Nick. [1] https://github.com/pypa/pip/issues/1668 -- Nick Coghlan | ncoghlan@xxxxxxxxx | Brisbane, Australia _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
