pip: Unexpected --user behavior since version 23.1

Description

Hey everyone, I’m using pip typically in virtual environments (managed by PyCharm). Since version 23.1 I get an error message when installing packages.

(venv) C:\Users\florian.wiese\PycharmProjects\GUIManager>pip --version
pip 23.1 from c:\users\florian.wiese\pycharmprojects\guimanager\venv\lib\site-packages\pip (python 3.9)

(venv) C:\Users\florian.wiese\PycharmProjects\GUIManager>pip install numpy
ERROR: Can not perform a '--user' install. User site-packages are not visible in this virtualenv.

A little research told me, that a --user flag within a venv does not really make sense. However, it seems that some kind of default --user is set since 23.1.

A workaround I found is to add the --no-user flag.

(venv) C:\Users\florian.wiese\PycharmProjects\GUIManager>pip install numpy --no-user
Collecting numpy
   Using cached numpy-1.24.2-cp39-cp39-win_amd64.whl (14.9 MB)
Installing collected packages: numpy
Successfully installed numpy-1.24.2

For completeness, downgrading to 23.0.1 with the --no-user flag gives the me the behavior I’m used to.

(venv) C:\Users\florian.wiese\PycharmProjects\GUIManager>pip --version
pip 23.1 from c:\users\florian.wiese\pycharmprojects\guimanager\venv\lib\site-packages\pip (python 3.9)

(venv) C:\Users\florian.wiese\PycharmProjects\GUIManager>python.exe -m pip install --upgrade pip==23.0.1 --no-user
Collecting pip==23.0.1
  Using cached pip-23.0.1-py3-none-any.whl (2.1 MB)
Installing collected packages: pip
  Attempting uninstall: pip
    Found existing installation: pip 23.1
    Uninstalling pip-23.1:
      Successfully uninstalled pip-23.1
Successfully installed pip-23.0.1

(venv) C:\Users\florian.wiese\PycharmProjects\GUIManager>pip install numpy
Collecting numpy
  Using cached numpy-1.24.2-cp39-cp39-win_amd64.whl (14.9 MB)
Installing collected packages: numpy
Successfully installed numpy-1.24.2

[notice] A new release of pip is available: 23.0.1 -> 23.1
[notice] To update, run: python.exe -m pip install --upgrade pip

Not sure if this is a bug or a feature. Maybe I’m also missing something very obvious. But at least it is documented now for anyone experiencing the same issue 😃

Expected behavior

No response

pip version

23.1

Python version

3.9

OS

Windows 10

How to Reproduce

create a venv with pip 23.1 try to install a package with pip install <any-package-name>

Output

ERROR: Can not perform a '--user' install. User site-packages are not visible in this virtualenv.

Code of Conduct

I agree to follow the PSF Code of Conduct.

About this issue

Original URL
State: closed
Created a year ago
Comments: 21 (16 by maintainers)

Most upvoted comments

By the way @flowmeadow, as a temporary workaround, you should be able to set the user option to false in a config file that’s higher priority than the “base” one (or just set $PIP_USER=0 in your environment).

pfmoore on Apr 20, 2023

Thanks for the heads up - I’ll fix that!

pfmoore on Apr 22, 2023

switch from the the Windows Store to winget and behave more like Linux distros?

Show me a Linux distro that downloads our installer and runs it with unreliable command line options and I’ll consider it (spoiler: no I won’t 😉 winget is not a good way to manage Python installs, I’m afraid).

just in case he wants to comment here (and maybe correct any misunderstandings)

I’ve put plenty of explanation on the CPython bug already. My fundamental disagreement is with configurations located in sys.base_prefix being used when sys.base_prefix != sys.prefix, as it makes it impossible to use a sys.prefix configuration in something that may be used as a base environment.

Perhaps sys.base_prefix configuration files should use a different filename, or different section names or something. Or some extra setting to say “please consider the settings in this file for venvs created from this environment”.

I can imagine useful scenarios for files in both sys.base_prefix and also sys.prefix when ==sys.base_prefix, but they all assume the distributor knows what you should use by default (e.g. platform name, index-url, etc.). If pip wants to say that distributors don’t know the right install locations, that’s fine, we distributors will just patch source files instead of adding overridable config settings.

zooba on Apr 20, 2023

@abhinavsingh that’s nothing to do with this issue. That’s the deprecation of pkg_resources, which is #11975 (and which is now fixed in main, and awaiting a bugfix release which will come once we’ve established what fixes we need to include).

pfmoore on Apr 20, 2023

Generally, I think the Store install should be fine. There’s some quirks like this, but they mostly seem to work. And having people use the distribution and report issues like you have is the only way we’ll know what needs improving, so your help is appreciated.

pfmoore on Apr 20, 2023