python.exe and other aliases not working before reinstalling the manager #370

Activity

1. zooba commented on Jun 16, 2026

   

   zooba

   on Jun 16, 2026

   Last edited by zooba

   Member

   More actions

   Hmm, all I can imagine here is that Windows somehow created corrupt shortcuts on the initial install. It's unlikely that anything would show up in the OS logs, as it would clearly be an unintended bug. Unfortunately, there are a few of those floating around in alias management, but they're never reproducible enough to get them fixed.

   If you (or anyone else) would like to make a PR adding the suggestion as a final fallback (it's really not going to do anything more for the most common problems, only the really obscure ones like yours), the file is Doc/using/windows.rst over in https://github.com/python/cpython.
2. zooba

   added

   enhancementNew feature or requestNew feature or request

   documentationImprovements or additions to documentationImprovements or additions to documentation

   and removed

   enhancementNew feature or requestNew feature or request

   on Jun 16, 2026
3. Vectorial1024 commented on Jul 8, 2026

   

   Vectorial1024

   on Jul 8, 2026

   More actions

   I recently ran into some problems with my Python installation and had to reinstall the Python Installation Manager. What I found was that PIM installed the py tool and the related files in %UserProfile%\AppData\Local\Microsoft\WindowsApps\PythonSoftwareFoundation.PythonManager_qbz5n2kfra8p0, which is clearly not in PATH, and also not the one specified in the setup hint for %UserProfile%\AppData\Local\Python\bin, and py.exe was also not inside %UserProfile%\AppData\Local\Python\bin.

   What this meant was that I got a fresh copy of Python 3.14 (thankfully is usable by prompt "add bin to PATH") but was unable to further configure my Python runtimes using py. The cmd would complain about e.g. "py is not found in this system".

   Adding the long PythonSoftwareFoundation path into the PATH environment variable fixed the issue for me. However, it seems best if PIM can automatically self-inject into PATH. For example, it feels like this py tool should also be copied over to the Python bin path, or at least a symlink should be dropped over to there.

   Not sure if related, but I took this opportunity to migrate my setup from the legacy "Python 3.xx" MS Store items to the now-recommended PIM setup, which also involved e.g. ghost entries of the legacy items that I had to remove by regedit. Apparently both the legacy Python items share the same space with PIM, so trying to uninstall PIM first (which removes the Python uninstaller afterwards) means that the legacy Python items cannot be uninstalled (same uninstaller, but is gone).
4. zooba commented on Jul 8, 2026

   

   zooba

   on Jul 8, 2026

   Member

   More actions

   Windows should already have %UserProfile%\AppData\Local\Microsoft\WindowsApps on PATH by default, and app execution aliases that are enabled (see "Manage app execution aliases" settings page on your PC) will be put in there.

   Sometimes people remove that directory from PATH. If you do that, Windows will respect your decision, but it means you don't get the commands by default. Put the path back and you'll have them. See the troubleshooting section at https://docs.python.org/using/windows for more info.

   Probably we need to detect when this path is missing from PATH and tell users that they've broken themselves somehow. But it's not our responsibility to put it there - Windows does it by default, and only manual changes will remove it (and if you've manually removed it, we can assume that you know how to manually put it back).

   Not sure if related, but I took this opportunity to migrate my setup from the legacy "Python 3.xx" MS Store items to the now-recommended PIM setup, which also involved e.g. ghost entries of the legacy items that I had to remove by regedit. Apparently both the legacy Python items share the same space with PIM, so trying to uninstall PIM first (which removes the Python uninstaller afterwards) means that the legacy Python items cannot be uninstalled (same uninstaller, but is gone).

   The Store items don't share anything with the install manager other than the WindowsApps entries I mentioned above (they have separate subdirectories for their commands, but when enabled globally will be in the WindowsApps directory together). There are no registry entries you should be touching for Store apps - you will have had to make security changes to your PC, and we can't help you if you've done that.

   Uninstalling the install manager will not affect uninstallers for any other Python runtimes. It will leave broken entries in Add/Remove Programs for anything that it has installed itself, but it doesn't overwrite anything created by a legacy installer. (The legacy installer might overwrite things created by the install manager, however.)

   So while this is concerning, and we don't want the install manager to prevent uninstalls of old runtimes, I don't see anything in your description that makes sense enough to identify a problem. More likely you just encountered bugs in the old installers, which is why we want to get rid of them.
5. segevfiner commented on Aug 6, 2026

   

   segevfiner

   on Aug 6, 2026

   More actions

   It seems some weird Windows bug on my computer somehow restored the shims in WindowsApps, while the execution aliases were still turned off (Probably the manager automatically turned them off at some point, like during install), so I had to enable and disable them again, in classic Windows restart to fix it philosophy to fix it.