Summary: | dev-python/pip: Disable running as root | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Patrick Lauer <patrick> |
Component: | [OLD] Unspecified | Assignee: | Python Gentoo Team <python> |
Status: | RESOLVED FIXED | ||
Severity: | critical | CC: | brainsburn, dschridde+gentoobugs, grknight, josef64, kenny.strawn, mgorny, zamabe |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Disable systemwide package install
debian patch better patch from debian Make Portage itself pip-installable |
Description
Patrick Lauer
2015-07-02 05:05:58 UTC
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. 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. 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. |