Repository navigation
The pip and py/python aliases refer to different installations whenever PYTHON_MANAGER_DEFAULT is anything but the most recent full release available. #413
Description
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:
- In a fresh sandbox VM, paste and execute
python-manager-26.3.msi - Install 3.14 and 3.15-dev
- Set PYTHON_MANAGER_DEFAULT to 3.15
- 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
pip install colorama(success)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.
Activity
Punisheroot commentedon Sep 10, 2026
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. SettingPYTHON_MANAGER_DEFAULTmarks a different install as the default, but does not appear to move it earlier in that ordering.That explains why
python.execan point to the configured default while a duplicated entrypoint such aspip.exestill 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
pipcommand should run in the same environment thatpythonandpydefault 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
defaulttake 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.zooba commentedon Sep 10, 2026
It looks like the overridden default setting doesn't actually reorder the interpreters as they are returned by
get_installs()internally, and theupdate_all_shortcutsfunction 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_shortcutsfunction 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 insideget_installsbased on a new (name-only) argument might be better. I don't want to change the order forpy listthough, so it can't be the default behaviour ofget_installsto put the default runtime first.Prefer default install for shared aliases (python#415)