Pipx cannot be install on windows

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

1. 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.

[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.

[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