Pipx cannot be install on windows

[hvaandres]

Describe the bug I'm currently trying to install pipx within my windows machine, and it seems that is not able to detect my path environmental variables because when you use the command pipx list is not able to recognized pipx. If I do pip list, I would be able to see that pipx is part of the list.

This is the error that I'm getting:

pipx : The term 'pipx' is not recognized as the name of a cmdlet, function, script file, or operable program. Check
the spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:1
+ pipx list
+ ~~~~
    + CategoryInfo          : ObjectNotFound: (pipx:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

How to reproduce

1. Open your terminal
2. Run the following command

python3 -m pip install --user pipx

3. Set up your path environmental variables

%USERPROFILE%\.local\bin
%USERPROFILE%\AppData\Roaming\Python\Python38\Scripts

Expected behavior

1. We should be able to have an error message that can tell us a little bit more of what could be the next step and what could resolve this situation. Also, inside of your documentation, you don't have a lot of information about getting issues with the installation.

[itsayellow]

Just to make sure you've seen this: https://pipxproject.github.io/pipx/installation/#install-pipx

If you've added these paths to your system PATH, then you may need to restart your shell, or possibly logout and login. Often new additions to the PATH are not immediately available in a running shell. If you use pipx ensurepath to add the paths it will actually tell you to restart your shell.

As for producing an error message, there's nothing that pipx can do here. The shell hasn't found pipx in your example, so our code is not actually running, and therefore we can't produce an error message... 🤷

[hvaandres]

I added the path, and it seems that is still an issue, I don't know what else to do. I made it work inside of WSL within Ubuntu, but I'm not sure what else I have to do for Windows.

[itsayellow]

It's hard to troubleshoot without more information, but here are some things you can check:

It seems like you're using Windows Powershell for your original bug report. If so, then the following examples should apply.

First see what your PATH is set to. Execute

echo $Env:Path

and check that the paths you intended to add to the system PATH actually show up in that list. If they don't, then the method isn't working to modify your PATH.

Another thing to check is that the pipx.exe binary is actually inside of %USERPROFILE%\AppData\Roaming\Python\Python38\Scripts

dir $Env:Userprofile\AppData\Roaming\Python\Python38\Scripts

Finally, you can actually try to use the full path to run pipx and see if it works. From your user home directory, execute:

AppData\Roaming\Python\Python38\Scripts\pipx.exe --version

[deepsp94]

I think I had the same issue. I noticed that %USERPROFILE%.local\bin had been added to the Path variable of USERPROFILE. I added it to Path variable for System variables too and pipx started working.

[iCurvaceous]

I had a similar issue, with cmd. What I did was search for pipx.exe, then I dragged it into my cmd and ensurepath. Once I did that my problem was still not resolved. I even opened in powershell and it said the same thing. Seems like the bug is in the ensurepath function. It's not setting the path correctly as user itsayellow thought.

Things to note: My python 3.8 is from windows store. I'm wondering if that is the issue. Python stores in a different folder when from the windows store. Not sure if thats something pipx devs have worked around in their ensurepath code. Anyways, on to manually setting the path with https://www.computerhope.com/issues/ch000549.htm#windows10

Edit: It worked!

[TBBle]

What's actually happening here is that pipx ensurepath is updating the registry, but not raising the WM_SETTINGCHANGE that tells the system about it. When you then go and manually edit your path through the control panel, even if you don't change the PATH env-var, WM_SETTINGCHANGE is raised when you hit "Okay" and console programs started after that, e.g. cmd and PowerShell, will see the new path.

So the actual fix would be to have pipx ensurepath raise WM_SETTINGCHANGE after editing the registry paths. (I believe the setx command-line utility also raises this signal). This might actually be missing functionality from https://github.com/ofek/userpath, i.e. at https://github.com/ofek/userpath/blob/b436d0f4170756ce0dc6b4eb1cf2e4ae2fd55d23/userpath/interface.py#L40-L49, rather than pipx itself.

This removes the need to logout or reboot that some users have observed, e.g., #589.

[pohlt]

We just tested this on Windows 10 with pipx 0.16.4 and saw a similar behavior as described above:

1. python3 -m pip install --user pipx
2. AppData\Roaming\Python\Python39\Scripts\pipx.exe ensurepath

%USERPROFILE%.local\binhad been added to PATH, but AppData\Roaming\Python\Python39\Scripts had not been added, although the ensurepath run said so.

[aryanshukla7]

Make sure to check that the CORRECT Path is added. Because for me ensure path did add the paths BUT........... the paths were technically incorrect, meaning that the path had lowercase characters, like instead of C:/Users/Name..... ensure path added, c:/users/name..... so once i changed it, it worked absolutely fine.

[pohlt]

I thought that Windows is case-insensitive with respect to paths... 🤔

[TBBle]

It is. I think what @aryannewyork saw is what I described earlier, that by going into the environment variable editor UI, making any change (to any env-var), and saving it, the WM_SETTINGCHANGE message is sent out and Explorer updates its copy of the env-vars and so new terminal sessions will see the new path.

As well as the link I gave earlier, there's a ton of discussion and detail on this mechanism in https://github.com/microsoft/terminal/issues/1125 as part of getting the same behaviour to work in Windows Terminal, but for new tabs, rather than restarting the whole process.

Edit: Turns out I never actually logged this as a feature-request with userpath, so I did now: https://github.com/ofek/userpath/issues/40

[TBBle]

And userpath 1.8.0 has added support for WM_SETTINGCHANGE, so new installs of pipx or pip install --upgrade userpath should pull that version of userpath.

As a quick local test, I removed the two paths from my PATH via the env-var editor UI, and then, in a new Windows Terminal session:

C:\Users\paulh
>pipx
pipx: The term 'pipx' is not recognized as a name of a cmdlet, function, script file, or executable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
C:\Users\paulh
>py -3 -m pipx ensurepath
Success! Added C:\Users\paulh\.local\bin to the PATH environment variable.
Success! Added C:\Users\paulh\AppData\Roaming\Python\Python39\Scripts to the PATH environment variable.

Consider adding shell completions for pipx. Run 'pipx completions' for instructions.

You will need to open a new terminal or re-login for the PATH changes to take effect.

Otherwise pipx is ready to go! ✨ 🌟 ✨

and doing nothing else, I opened a new cmd.exe session from the Start Menu and:

Microsoft Windows [Version 10.0.19042.1466]
(c) Microsoft Corporation. All rights reserved.

C:\Users\paulh>pipx
usage: pipx [-h] [--version]
            {install,inject,upgrade,upgrade-all,uninstall,uninstall-all,reinstall,reinstall-all,list,run,runpip,ensurepath,completions}
            ...

Note that a new tab or window from the same Windows Terminal session does not see the updated PATH, pending implementation of https://github.com/microsoft/terminal/issues/1125, but ConEmu for example would see the updated PATH in a new tab.

I'm not sure that's what this bug was originally opened for, but it's nice, and should avoid the accidental-solutions of "ensurepath didn't work, but then I edited the path, and it started working"..

Note: I did the same test with opening a new Windows Terminal session, but it saw pipx even with userpath==1.7.0. cmd.exe as the second process failed this same test with userpath==1.7.0, so I suspect Windows Terminal is getting a fresh environment block on startup, while cmd (and most things, I assume) relies on the environment inherited from Explorer.

[pohlt]

Hi all, thanks for looking into this issue and your work on pipx in general. I'll check it with the next install under Windows.

[gaborbernat]

Hi all, thanks for looking into this issue and your work on pipx in general. I'll check it with the next install under Windows.