Description

hungarian-notation

opened on Sep 10, 2026

Issue body actions

Install source and version

• Installed from the Windows Store
• Installed with the MSIX from python.org
• Installed with the MSI from python.org
• Installed with winget install 9NQ7512CXL7T

Version: 26.3

Describe the bug
The pip alias appears to be hard-coded to point to the newest full release, creating a surprising scenario where the pip and python available on the path may be from different installations.

To Reproduce
Steps to reproduce the behavior:

0. In a fresh sandbox VM, paste and execute python-manager-26.3.msi
1. Install 3.14 and 3.15-dev
2. Set PYTHON_MANAGER_DEFAULT to 3.15
3. Run py install --refresh

Python 3.14.7 will be launched by python3[-64].exe, python3.14[-64].exe
Python 3.15.0rc2 will be launched by python.exe and also python3.15[-64].exe

4. pip install colorama (success)
5. py -c "import colorama" (ModuleNotFoundError)

The pip invoked at step four is from Python 3.14, but the python invoked in step five is from Python 3.15.

Expected behavior
If the installer is going to maintain a pip in my path it should refer to the same installation as the python it also maintains. Perhaps the installer should instead place a pip.exe in the path that simply admonishes the user to use py -m pip instead.

Additional Context
The fact that 3.15 is a release candidate is irrelevant except that I expect pip would always point to it instead of 3.14 if it were a full release. The same behavior occurs when PYTHON_MANAGER_DEFAULT=3.13 and you have 3.13 and 3.14 installed.

reproduction console session

Activity

1. Punisheroot commented on Sep 10, 2026

   

   Punisheroot

   on Sep 10, 2026

   Contributor

   More actions

   I think this may be worth clarifying in terms of the intended precedence for generated entrypoint aliases.

   The current behavior seems consistent with the general “first match wins” rule for global aliases: installs are processed in their normal preference order, and create_aliases() skips an entrypoint name once it has already been written. Setting PYTHON_MANAGER_DEFAULT marks a different install as the default, but does not appear to move it earlier in that ordering.

   That explains why python.exe can point to the configured default while a duplicated entrypoint such as pip.exe still comes from the first preferred install.

   What makes me unsure whether this is intentional is the earlier discussion in #140. In particular, @pfmoore noted there that the global pip command should run in the same environment that python and py default to, and #225 was later described as fixing that request by generating shortcuts from registered entrypoints.

   So I think the key question is: when the same generated entrypoint exists in multiple managed runtimes, should the runtime marked as default take precedence over the normal install ordering?

   If the current first-match behavior is intentional even for duplicated entrypoints such as pip, then this may simply be exposing that design choice. Otherwise, this looks like a case that was not covered when entrypoint shortcut generation was added.
2. zooba commented on Sep 10, 2026

   

   zooba

   on Sep 10, 2026

   Member

   More actions

   It looks like the overridden default setting doesn't actually reorder the interpreters as they are returned by get_installs() internally, and the update_all_shortcuts function assumes that the default is first and the rest of the list is in order of precedence (which it is, apart from the default).

   We should make update_all_shortcuts function find the default install and move it to the front of the list before doing its processing. If there are more places where this might matter, then doing the move inside get_installs based on a new (name-only) argument might be better. I don't want to change the order for py list though, so it can't be the default behaviour of get_installs to put the default runtime first.

   Reacted by JS
3. zooba

   closed this as completedin #415on Sep 10, 2026
4. hamzajazib

   added a commit that references this issue on Sep 11, 2026

   Prefer default install for shared aliases (python#415)

   This issue will close once commit d14e65d is merged into the 'main' branch.

   d14e65d

Issue actions