Maybe `sudo pip install` should: - create a chroot && mkdir --prefix - drop privileges* - pip install - chown -R root:root - mv chroot/prefix/* prefix/
In most cases, the user does not need to run the (unreviewed, unsigned) code as root; neither should they run the (unreviewed, unsigned) setup.py as root. All a wheel needs to be installed is an unzip.* On Friday, May 25, 2018, Victor Stinner <vstin...@redhat.com> wrote: > As an user, I want to use "sudo pip install" because packages > installed in /usr (or /usr/local) are accessible without having to > touch PYTHONPATH: the install directory is part of the default > sys.path. > > Steve Dower also proposed the idea of a "default virtual environment" > somewhere in the $HOME directory which would be in the default > sys.path. > > Victor > > 2018-05-23 21:47 GMT+02:00 Alex Walters <tritium-l...@sdamon.com>: > > I think the obvious, if socially hard solution, is to make pip panic > when it > > sees its being run as root (without, perhaps, a flag to tell pip "No, I > > really mean it, run as root"), and default to --user. It is not a good > idea > > to install packages system wide with pip for reasons more than just > > clobbering apt/dnf installed packages. I still think the best idea for > > getting a python program to run system wide is either A: symlink from a > > inside a venv into something on $PATH, B: just set a shebang to the > python > > in a venv, or C: bundle your application into a .deb or .rpm and use the > > system package manager to install it. > > > >> -----Original Message----- > >> From: Victor Stinner <vstin...@redhat.com> > >> Sent: Wednesday, May 23, 2018 11:22 AM > >> To: distutils-sig@python.org > >> Subject: [Distutils] sudo pip install: install pip files into /usr/local > > on Linux? > >> > >> Hi, > >> > >> pip is currently not well integrated on Linux: it conflicts with the > >> system package manager like apt or rpm. When pip writes files into > >> /usr, it can replace files written by the system package manager and > >> so create different kind of issues. For example, if you check the > >> system integry, you will likely see that some Python files have been > >> modified. > >> > >> I would like to open a discussion to see how each Linux vendor handles > >> the issue, and see if a common solution can be designed. > >> > >> Debian uses /usr for apt-get install and /usr/local for distutils and > >> "sudo pip". > >> > >> Fedora decided to change pip to install files into /usr/local by > >> default, instead of /usr, so "sudo pip install" doesn't replace files > >> installed by dnf (Fedora package manager): > >> https://fedoraproject.org/wiki/Changes/Making_sudo_pip_safe > >> > >> It gives you 3 main places to install Python code: /usr (managed by > >> dnf), /usr/local (managed by sudo pip), $HOME/.local (managed by pip > >> --user). > >> > >> Would it make sense to make the Fedora/Debian change upstream? At > >> least, give an opt-in option for Linux vendors to use /usr/local? > >> > >> I propose to make the change upstream because there are still issues, > >> and I don't want to be alone to have to fix them :-) It should be > >> easier if we agree on a filesystem layout and an implementation, so > >> we can collaborate on issues! > >> > >> > >> Issues with the current Fedora implementation: > >> > >> (1) When Python is embedded in an application, there is an issue with > >> the current heuristic to decide if /usr/local should be added to > >> sys.path: > >> > >> https://bugzilla.redhat.com/show_bug.cgi?id=1532287 > >> > >> (2) On Fedora, "sudo pip install -U" currently removes old code from > >> /usr and install the new one in /usr/local. We should leave /usr > >> unchanged, since only dnf should touch /usr. > >> > >> https://bugzilla.redhat.com/show_bug.cgi?id=1550368#c24 > >> > >> The implementation is made of a single patch on the Python site module: > >> > >> https://src.fedoraproject.org/rpms/python3/blob/master/f/00251-change- > >> user-install-location.patch > >> > >> -- > >> > >> There are two issues related to the "sudo pip" change, but they > >> already exist when pip is installed in $HOME/.local: > >> > >> (3) Priority issue between PATH and PYTHONPATH directories. > >> > >> When the user runs "pip", the pip binary may come from /usr, > >> /usr/local or $HOME/.local/bin, but the Python pip module ("import > >> pip") may come from a different path. Which binary and which module > >> should be used? > >> > >> Obvisouly, users can replace these two environment variables... > >> > >> (4) Related to (3). Running "pip" may run pip binary of one pip > >> version, but pick the "pip" Python module of another pip version. > >> > >> For example, pip9 binary from /usr/bin/pip, but pip10 module from > >> /usr/local. > >> > >> > >> Fedora works around issue (4) with a downstream patch on pip: > >> > >> https://src.fedoraproject.org/rpms/python-pip/blob/master/f/pip9-allow- > >> pip10-import.patch > >> > >> -- > >> > >> I don't well well how Linux distributions handle the issue with "sudo > >> pip". So don't hesitate to correct me if I'm wrong :-) My goal is > >> just to start a discussion about a common "upstream" solution. > >> > >> Victor > >> -- > >> Distutils-SIG mailing list > >> distutils-sig@python.org > >> https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ > >> Message archived at https://mail.python.org/mm3/ > archives/list/distutils- > >> s...@python.org/message/OLGLHTSHLEPLHUTTVNU6L5QFTMNFIB6Z/ > > > -- > Distutils-SIG mailing list > distutils-sig@python.org > https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ > Message archived at https://mail.python.org/mm3/ > archives/list/distutils-sig@python.org/message/ > 3FIFTWKLXC6Y6QI5XI7ZA2J2XEYS4A6J/ >
-- Distutils-SIG mailing list distutils-sig@python.org https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/XOCQZ2ANEE6E3GVI7A6EJJTCSPHC6WNV/
