Ahoi, when run as root pip tends to nuke python-exec, which then breaks pretty much all python apps installed through portage. This is a known stupidity and should be patched out of pip, I'd suggest exit(-1) when run as root. (It's such a furball of indirections that I have no idea what is called how, so I can't figure out what to patch. Yeargh!)
Do we have a reproducible test case for this? I have seen many related bugs, but I can recall anybody telling us exactly what they installed with pip that overwrote python-exec. I want to make sure this is a really problem with pip, rather than distutils or setuptools.
Well, I think the core issue here is that pip installs into /usr. I think it might be a better solution to just make it install into /root (like it does homedir installs for regular users, and like CPAN works).
pip only does a homedir install if you pass --user. pip install --user setuptools Otherwise, it defaults to a system-wide install, regardless of the current UID.
Of course, we can patch that behavior; I'm just clarifying how it currently works.
(In reply to Mike Gilbert from comment #1) > Do we have a reproducible test case for this? > > I have seen many related bugs, but I can recall anybody telling us exactly > what they installed with pip that overwrote python-exec. > > I want to make sure this is a really problem with pip, rather than distutils > or setuptools. A user in #gentoo said he executed "sudo pip install -U mopidy" and it broke python-exec. I started to investigate and the same command did not break on ~amd64. grknight@akame ~/mysql-extras $ sudo pip install -U mopidy Collecting mopidy Downloading Mopidy-1.1.1-py2.py3-none-any.whl (202kB) 100% | | 204kB 138kB/s Collecting Pykka>=1.1 (from mopidy) Downloading Pykka-1.2.1-py2.py3-none-any.whl Collecting tornado>=2.3 (from mopidy) Downloading tornado-4.2.1.tar.gz (434kB) 100% | | 438kB 483kB/s Requirement already up-to-date: requests>=2.0 in /usr/lib64/python3.4/site-packages (from mopidy) Requirement already up-to-date: setuptools in /usr/lib64/python3.4/site-packages (from mopidy) Installing collected packages: Pykka, tornado, mopidy Running setup.py install for tornado Successfully installed Pykka-1.2.1 mopidy-1.1.1 tornado-4.2.1 So i started from a blank, stable VM and python-exec broke. The same command installed a new version of setuptools and now `pip --version` reports: "setuptools 18.4 from /usr/lib/python2.7/site-packages"
Created attachment 415590 [details, diff] Disable systemwide package install Please give this patch a try. It should prevent pip install from being run without the --target, --root, or --user options.
Doesn't this break virtualenv?
(In reply to Michał Górny from comment #7) > Doesn't this break virtualenv? I don't know. Please test it and let me know if it does.
virtualenv seems to install its own fresh, unpatched copy of pip unless you pas --no-pip to it.
https://bugs.gentoo.org/show_bug.cgi?id=564836
alternatively, it could be used as root, but by default pip could install everything into /usr/local to not mess things. i believe Debian have their pip working that way.
https://bugzilla.redhat.com/show_bug.cgi?id=662034#c10
https://bugzilla.redhat.com/show_bug.cgi?id=662034
https://github.com/pypa/pip/issues/1668 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771794
Created attachment 424606 [details, diff] debian patch
Created attachment 424608 [details, diff] better patch from debian sorry, previous attachment broken
commit 698a23d83720989123978eb212b387bc5fe96e4a Author: Mike Gilbert <floppym@gentoo.org> Date: Tue Jan 3 23:28:30 2017 -0500 dev-python/pip: disable systemwide installs Bug: https://bugs.gentoo.org/553762 Package-Manager: Portage-2.3.3_p13, Repoman-2.3.1_p6 .../pip/files/pip-disable-system-install.patch | 29 ++++++++++++++++++++++ .../pip/{pip-9.0.1.ebuild => pip-9.0.1-r1.ebuild} | 12 ++++----- 2 files changed, 34 insertions(+), 7 deletions(-)
I guess that will also prevent people from cleaning packages already installed by pip out. But then, that was unsafe anyway.
Latest PIP version did not work with virtualenvs. I have several virtual envs for my projects. Today I tried to update Django which is installed in virtual env and got this error: $ pip install -U django ERROR: (Gentoo) Please run pip with the --user option to avoid breaking python-exec Is there possibility to ignore it?
Also I don't understand why I getting that error when I run PIP as non-root user. It can not damage system anyway.
(In reply to Brainsburn from comment #19) Please give exact steps to reproduce the problem.
(In reply to Mike Gilbert from comment #21) > Please give exact steps to reproduce the problem. There is virtualenv and Django-1.10.2 installed in virtual enviroment named "testing". I'm trying to update Django: # emerge =pip-9.0.1-r1 $ workon testing # <- virtualenvwrapper's command to activate virtual environment $ pip show Django Name: Django Version: 1.10.2 Location: /myworkdir/testing/lib/python2.7/site-packages $ pip install -U Django ERROR: (Gentoo) Please run pip with the --user option to avoid breaking python-exec $ pip install -U Django --user Successfully installed Django-1.10.5 $ pip show Django Name: Django Version: 1.10.2 Location: /myworkdir/testing/lib/python2.7/site-packages The problem is that I need to install Django to "myworkdir/testing/" but with --user option it installs somewhere in ~/.local/
I cannot reproduce the problem. The virtualenv uses its own, unaltered copy of pip, and does not display the (Gentoo) message. floppym@naomi ~ % equery l pip * Searching for pip ... [IP-] [ ] dev-python/pip-9.0.1-r1:0 floppym@naomi ~ % mkdir .venv floppym@naomi ~ % export WORKON_HOME=$HOME/.venv floppym@naomi ~ % . /usr/bin/virtualenvwrapper.sh virtualenvwrapper.user_scripts creating /home/floppym/.venv/initialize virtualenvwrapper.user_scripts creating /home/floppym/.venv/premkvirtualenv virtualenvwrapper.user_scripts creating /home/floppym/.venv/postmkvirtualenv virtualenvwrapper.user_scripts creating /home/floppym/.venv/prermvirtualenv virtualenvwrapper.user_scripts creating /home/floppym/.venv/postrmvirtualenv virtualenvwrapper.user_scripts creating /home/floppym/.venv/predeactivate virtualenvwrapper.user_scripts creating /home/floppym/.venv/postdeactivate virtualenvwrapper.user_scripts creating /home/floppym/.venv/preactivate virtualenvwrapper.user_scripts creating /home/floppym/.venv/postactivate virtualenvwrapper.user_scripts creating /home/floppym/.venv/get_env_details virtualenvwrapper.user_scripts creating /home/floppym/.venv/premkproject virtualenvwrapper.user_scripts creating /home/floppym/.venv/postmkproject floppym@naomi ~ % workon floppym@naomi ~ % mkvirtualenv testing Using base prefix '/usr' New python executable in /home/floppym/.venv/testing/bin/python3.5 Also creating executable in /home/floppym/.venv/testing/bin/python Installing setuptools, pip, wheel...done. virtualenvwrapper.user_scripts creating /home/floppym/.venv/testing/bin/predeactivate virtualenvwrapper.user_scripts creating /home/floppym/.venv/testing/bin/postdeactivate virtualenvwrapper.user_scripts creating /home/floppym/.venv/testing/bin/preactivate virtualenvwrapper.user_scripts creating /home/floppym/.venv/testing/bin/postactivate virtualenvwrapper.user_scripts creating /home/floppym/.venv/testing/bin/get_env_details (testing) floppym@naomi ~ % pip install "Django == 1.10.2" Collecting Django==1.10.2 Downloading Django-1.10.2-py2.py3-none-any.whl (6.8MB) Installing collected packages: Django Successfully installed Django-1.10.2 (testing) floppym@naomi ~ % pip show Django Name: Django Version: 1.10.2 Summary: A high-level Python Web framework that encourages rapid development and clean, pragmatic design. Home-page: http://www.djangoproject.com/ Author: Django Software Foundation Author-email: foundation@djangoproject.com License: BSD Location: /home/floppym/.venv/testing/lib/python3.5/site-packages Requires: (testing) floppym@naomi ~ % pip install -U Django Collecting Django Using cached Django-1.10.5-py2.py3-none-any.whl Installing collected packages: Django Found existing installation: Django 1.10.2 Uninstalling Django-1.10.2: Successfully uninstalled Django-1.10.2 Successfully installed Django-1.10.5
Oh I think I got it. Probably my virtualenv was created with "--no-pip" option. Without this option pip works fine. Sorry that I bothered you.
(In reply to Brainsburn from comment #24) Ah, that would make sense. No worries, I'm glad to get the feedback.
Is there a reason this is still open?
Created attachment 594716 [details, diff] Make Portage itself pip-installable Apply my patch and you'll be able to pack Portage as 'portage-2.3.78-py3-none-any.whl' and upload it to PyPI. Much cleaner solution than having to throw an error whenever pip is run as root, one would imagine.
https://pypi.org/project/portage/2.3.78/ In case there was any doubt about my solution working ― hear, hear.
Removed the test build from PyPI due to failure to bundle some important scripts (need to modify setup.py some more), but the fact that this does still produce a working installable package should be noted. It kind of renders the errors moot.
(In reply to Matthew Thode ( prometheanfire ) from comment #26) > Is there a reason this is still open? I'd guess we were waiting for old versions to disappear.
