Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

~/.pip/pip.conf and virtualenv conflict #2081

Closed
ajford opened this issue Oct 2, 2014 · 8 comments
Closed

~/.pip/pip.conf and virtualenv conflict #2081

ajford opened this issue Oct 2, 2014 · 8 comments
Labels
C: configuration Configuration management and loading project: virtualenv Related to virtualenv type: bug A confirmed bug or unintended behavior

Comments

@ajford
Copy link

ajford commented Oct 2, 2014

I couldn't find this issue documented anywhere, but if you specify install-option in ~/.pip/pip.conf, it is not overriden by virtualenv. I specify --prefix=/path/to/somwhere in install-option due to user restrictions on my work pc, and with it set, any installs in a venv (with $PIP_RESPECT_VIRTUALENV enabled) still install in the path specified by install-option. This was not an expected behavior for me, but I'm not sure if ignoring pip.conf is the correct course of action either. Perhaps documenting such behavior is best. Another odd thing is that you then cannot uninstall while in the virtualenv, as the package is not installed in the venv, and pip cannot find it.

This happened to me when using pip 1.4.1 and 1.5.6 and virtualenv 1.11.6.

@ajford
Copy link
Author

ajford commented Oct 2, 2014

My current fix is to set $PIP_CONFIG_FILE to /dev/null via virtualenvwrapper's postactivate hook and unsetting it in postdeactivate.

@anntzer
Copy link
Contributor

anntzer commented Jun 15, 2016

This issue is still present. In my case, I'd like to use --user installs when not in a venv (via setting this in ~/.config/pip/pip.conf, but "normal" (in-venv) installs when in a venv (do --user installs even make sense in a venv?).

Two possible solutions (of which only the first one can really be implemented by pip, but I may as well start the discussion here) are

  • provide a configuration file location that is only used outside of venvs (~/.config/pip/pip-novenv.conf or whatever), or
  • make --user a no-op in a venv (again, I'm not sure --user + venv make sense: there's only one ~/.local/lib/pythonX.Y so all isolation is broken there).

@hmijail
Copy link

hmijail commented Jun 18, 2017

Issue still present in Python 3.5.3.

It's pretty ironic and frustrating that if one tries to be careful with the environment, to the point of using virtual environments and user installs in pip.conf, one ends with a non-working system.

I was trying to avoid having team members use sudo pip. It keeps getting harder.

@pradyunsg pradyunsg added state: awaiting PR Feature discussed, PR is needed type: bug A confirmed bug or unintended behavior project: virtualenv Related to virtualenv labels Oct 2, 2017
@alexanderkjeldaas
Copy link

alexanderkjeldaas commented Sep 20, 2018

Isn't this a bug in virtualenv - that it doesn't set PIP_CONFIG_FILE=/dev/null when using some option?
Oh, got bitten by this today.

@pradyunsg
Copy link
Member

Can someone please provide clear instructions on how to reproduce this?

@pradyunsg pradyunsg added state: needs reproducer Need to reproduce issue and removed state: awaiting PR Feature discussed, PR is needed labels Oct 7, 2019
@layday
Copy link
Member

layday commented Feb 27, 2021

$ python -m pip config set install.user 1
Writing to /Users/layday/.config/pip/pip.conf
$ python -m venv venv
$ source venv/bin/activate
$ python -m pip install pip
ERROR: Can not perform a '--user' install. User site-packages are not visible in this virtualenv.

@pradyunsg pradyunsg added C: configuration Configuration management and loading and removed state: needs reproducer Need to reproduce issue labels Apr 29, 2022
@pradyunsg
Copy link
Member

You should no longer need to set python -m pip config set install.user 1 to make pip avoid the system installation mode.

Since pip 20.0, if the global site-packages are not-writable, pip will automatically use the user site-packages. This won't make sudo pip safe, but it does mean that regular usage will "just work".

@pradyunsg
Copy link
Member

Given that no one has reported wanting to set this flag since pip 20.0 was released, I'm gonna go ahead and say that this is resolved.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 30, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
C: configuration Configuration management and loading project: virtualenv Related to virtualenv type: bug A confirmed bug or unintended behavior
Projects
None yet
Development

No branches or pull requests

6 participants