Problem installing pipenv

In the book Django for Beginners it says to use pipenv and that worked. Later it says to use pipenv and Windows says it is not valid. So I tried to install it again and am having the following problem. (Probably a virtualenv problem?)

I am using Windows 10. I have Python 3.9 installed in the following locations.

  • C:\Program Files\Python39
  • c:\users\sam\appdata\roaming\python\python39

I want to use the all-users installation. If uninstalling the single-user installation will solve the problem then that is good.

I have the following in my system path and nothing relevant I can see in my user’s path environment variable.

  • C:\Program Files\Python39\
  • C:\Program Files\Python39\Scripts\

When I try to install pipenv I get the following.

C:\WINDOWS\system32>pip3 install pipenv
Requirement already satisfied: pipenv in c:\users\sam\appdata\roaming\python\python39\site-packages (2021.5.29)
Requirement already satisfied: virtualenv in c:\users\sam\appdata\roaming\python\python39\site-packages (from pipenv) (20.7.2)
Requirement already satisfied: virtualenv-clone>=0.2.5 in c:\users\sam\appdata\roaming\python\python39\site-packages (from pipenv) (0.5.6)
Requirement already satisfied: setuptools>=36.2.1 in c:\program files\python39\lib\site-packages (from pipenv) (57.4.0)
Requirement already satisfied: pip>=18.0 in c:\users\sam\appdata\roaming\python\python39\site-packages (from pipenv) (21.2.4)
Requirement already satisfied: certifi in c:\users\sam\appdata\roaming\python\python39\site-packages (from pipenv) (2021.5.30)
Requirement already satisfied: backports.entry-points-selectable>=1.0.4 in c:\users\sam\appdata\roaming\python\python39\site-packages (from virtualenv->pipenv) (1.1.0)
Requirement already satisfied: platformdirs<3,>=2 in c:\users\sam\appdata\roaming\python\python39\site-packages (from virtualenv->pipenv) (2.3.0)
Requirement already satisfied: distlib<1,>=0.3.1 in c:\users\sam\appdata\roaming\python\python39\site-packages (from virtualenv->pipenv) (0.3.2)
Requirement already satisfied: six<2,>=1.9.0 in c:\users\sam\appdata\roaming\python\python39\site-packages (from virtualenv->pipenv) (1.16.0)
Requirement already satisfied: filelock<4,>=3.0.0 in c:\users\sam\appdata\roaming\python\python39\site-packages (from virtualenv->pipenv) (3.0.12)

Somehow it is finding the single-user installation and I do not understand how. It seems to be finding a virtualenv specifying the single-user installation. Can I remove or at least deactivate it? How do I do that? Will that solve the problem? If not then what do I need to do to use pipenv?

In Windows you can write where pip3 to see where the command that will be used is. What does that output?
Also try where python, py --list-paths, and set PATH.

You can use C:\Program Files\Python39\Scripts\pip3 explicitly.
You can also use python -m pip to make sure the same pip belonging to the currently active python is used.

C:\Users\Sam>where pip3
C:\Program Files\Python39\Scripts\pip3.exe

C:\Users\Sam>where python
C:\Program Files\Python39\python.exe
C:\Users\Sam\AppData\Local\Microsoft\WindowsApps\python.exe

I am not sure where the Microsoft\WindowsApps installation came from, but probably it was installed by Visual Studio (not Visual Studio Code; Visual Studio is older and does much more).

set PATH shows the path as I described.

Using C:\Program Files\Python39\Scripts\pip3 explicitly I get:

C:\WINDOWS\system32>"C:\Program Files\Python39\Scripts\pip3" install pipenv
Requirement already satisfied: pipenv in c:\users\sam\appdata\roaming\python\python39\site-packages (2021.5.29)
Requirement already satisfied: virtualenv in c:\users\sam\appdata\roaming\python\python39\site-packages (from pipenv) (20.7.2)
Requirement already satisfied: pip>=18.0 in c:\users\sam\appdata\roaming\python\python39\site-packages (from pipenv) (21.2.4)
Requirement already satisfied: certifi in c:\users\sam\appdata\roaming\python\python39\site-packages (from pipenv) (2021.5.30)
Requirement already satisfied: virtualenv-clone>=0.2.5 in c:\users\sam\appdata\roaming\python\python39\site-packages (from pipenv) (0.5.6)
Requirement already satisfied: setuptools>=36.2.1 in c:\program files\python39\lib\site-packages (from pipenv) (57.4.0)
Requirement already satisfied: filelock<4,>=3.0.0 in c:\users\sam\appdata\roaming\python\python39\site-packages (from virtualenv->pipenv) (3.0.12)
Requirement already satisfied: six<2,>=1.9.0 in c:\users\sam\appdata\roaming\python\python39\site-packages (from virtualenv->pipenv) (1.16.0)
Requirement already satisfied: distlib<1,>=0.3.1 in c:\users\sam\appdata\roaming\python\python39\site-packages (from virtualenv->pipenv) (0.3.2)
Requirement already satisfied: platformdirs<3,>=2 in c:\users\sam\appdata\roaming\python\python39\site-packages (from virtualenv->pipenv) (2.3.0)
Requirement already satisfied: backports.entry-points-selectable>=1.0.4 in c:\users\sam\appdata\roaming\python\python39\site-packages (from virtualenv->pipenv) (1.1.0)

In both attempts, I first tried installing pipenv without administrator privileges. When I did I got:

Defaulting to user installation because normal site-packages is not writeable

And after that I got messages similar to the attempts with elevated privileges. If installing with lower privileges caused a permanent change that is causing the problem then I should have mentioned that sooner.

Using python -m pip install pipenv gets the same results.

Somehow it is using the single-user installation and whatever it is, it is a Python thing, not Windows.

Investigating the Microsoft\WindowsApps installation I found:

I am not sure what to do about that. I avoid unsupported solutions, such as deleting the file myself. I disabled python in Apps and Features but that did not have an affect; I will try a system restart later. If people here do not know how to solve the problem then I will try posting in the Microsoft Q&A forum, I assume this is a Microsoft problem.

I don’t think the WindowsApps thing matters here. Only the first one shown by where is actually used.

I’m surprised explicitly calling C:\Program Files\Python39\Scripts\pip3 still uses the c:\users\sam\appdata\roaming\python\python39\site-packages.

Maybe check if you have a pip.ini file in one of these locations.

I see no pip or python folder in my C:\ProgramData. I see no pip.ini in my APPDATA folder (searching all subfolders). I am not sure what %VIRTUAL_ENV%\pip.ini means but there is no environment variable VIRTUAL_ENV. There is also no environment variable PIP_CONFIG_FILE.

Here’s why your pipenv is installed where it is, anyway. I didn’t know pip had this functionality - it may be new - but I suppose it makes sense. If you have a system-wide Python and you try to install something without admin rights, there’s a fallback. You don’t have two Python installations, there are just multiple places Python looks for packages.

I should think you can just use the packages installed in your user home directory. Start Python and check the contents of sys.path - I imagine ...\appdata\roaming\... should be listed. There should be a Scripts directory containing pipenv.exe (and some other programs) somewhere in that appdata subdirectory as well, which you may want to add to your PATH.

Alternatively, deleting c:\users\sam\appdata\roaming\python\ completely and then reinstalling the packages you want in the system installation should be safe.

2 Likes

I moved my C:\Users\Sam\AppData\Roaming\Python\Python39 elsewhere and that got me back on track. I was not sure if that would cause a problem so thank you for saying it should be okay.

That sys.path is interesting, I had not seen that before. It does seem to be dynamic.

The feature of pipenv of which it decides what place to install into seems useful but the problem I think is that once it decides to use the single-user place (is place the official term?) then that decision becomes permanent.

Python has plenty of ways to specify a version but it seems to have little or no way to specify whether to use a single-user place or all-users place.

Part of the problem might be that Visual Studio attempts to manage Python and that might have caused a problem. I am using an older version of VS that does not support Python 3.9 so it is safe for me to eliminate that version if I want so that is why I moved only the 3.9 single-user place.