`pymanager install` says `python` will run 3.13, but it doesn't

[pfmoore]

Describe the bug
See https://discuss.python.org/t/python-3-14-0-beta-1-is-here/91117/16 for some background.

I have Python 3.13 installed from the old MSI installer. I did not uninstall it, but I installed the new pymanager from the python.org site. I chose "run after install" which installed Python 3.14b0. Once that had run, the python app alias started 3.14b0 (after I re-enabled it, I'd had it disabled rather than start the store Python).

I then tried to install 3.13 via pymanager install 3.13. I got the following output:

Installing Python 3.13.2.
Downloading: ..................................................................✅
Extracting: ...................................................................✅
[WARNING] A runtime matching PythonCore\3.13 is already installed, and so the new one has not been registered.
To register the new installation, remove the existing runtime and then run 'py install --refresh'

Global shortcuts directory is not on PATH. Add it for easy access to global Python commands.
Directory to add: C:\Users\Gustav\AppData\Local\Python\bin

Python 3.13.2 will be launched by python3-64.exe, python3.13-64.exe, python3.13.exe, python3.exe, pythonw3-64.exe, pythonw3.13-64.exe, pythonw3.13.exe, pythonw3.exe

The warning is not a surprise, and I'm fine with this. However, the final statement that Python 3.13.2 will be launched by various aliases, is not true. python3 still runs 3.14b0. python3.13 gives "python3.13: The term 'python3.13' is not recognized as a name of a cmdlet, function, script file, or executable program." The -64 versions all give "not recognised" (even 3-64, which I expected to run 3.14b0, like 3 does).

I don't know how relevant it is, but in "App Execution Aliases", I only see pythonw.exe, python.exe, python3.exe, pymanager.exe, py.exe, pywmanager.exe and pyw.exe. All are shown as "on". The versioned executables and the -64 ones are not present.

To Reproduce
See above - I don't have a self-contained reproducer, sorry.

Expected behavior
The various aliases should behave as described.

Additional context

python_install_20250509153247_24328.log

[zooba]

Okay, I'm fairly certain the issue here is showing both the PATH warning and the aliases, so the easiest change is to only show one or the other (that is, if we detect that the directory isn't on PATH, output stops right after that warning).

Does that sound reasonable?

[pfmoore]

Agreed.

I'd also question the extensive list of aliases. That seems more confusing than helpful. I'd restrict it to python3.exe and python3.13.exe. The rest seem like things that would only be needed in specialised cases, and finding them in the docs is enough.

By the way, I don't have a means to test this right now, but I assume that python3.exe will only be mentioned if it points to this version of Python? So, if I have 3.13 installed, installing 3.12 won't change python3.exe to run Python 3.12, and won't list python3.exe in the aliases message?

[zooba]

I'd also question the extensive list of aliases.

I'm trimming it right now. As I've said elsewhere, I don't want to special case ourselves too much, but it seems reasonable to hide the windowed aliases unless you've passed -v. It's a shame that we ourselves have so many aliases, but they're all ones that people expect/need, so someone has to concede a change in functionality 🤷‍♂

I assume that python3.exe will only be mentioned if it points to this version of Python?

Correct. This is why we always refresh all of them - we need to iterate through all the installs in order to "consume" aliases, so that when (a managed install of) 3.13 shows up first, it wins the python3.exe alias, and a 3.12 shows up later and doesn't get it even though it requested it. The printed message does the same trick.

[pfmoore]

It's a shame that we ourselves have so many aliases, but they're all ones that people expect/need, so someone has to concede a change in functionality

I'm not saying don't have the extra aliases, just don't bother mentioning them. Anyone who needs them will know about them, I expect.

[zooba]

The problem is there's no universal definition of "extra" when it comes to aliases. Perhaps I could've added another field for "hide by default", but doing that now would require repackaging/publishing all the old versions again. Not impossible, but I'd prefer to find ways to reduce the cognitive burden that will work for anyone's aliases - assuming that a trailing 'w' followed by numbers/dots might be an optional flag rather than a different name is as specialised as I want to get.

[AA-Turner]

I would also suggest hiding the -64 suffixes (unless already planned), it creates more confusion over if the unsuffixed executables are 64-bit or not.

[zooba]

Those will show as optional - python3[-64].exe (based on whether the same runtime also has python3.exe aliases - if it doesn't, they won't show as optional).

[AA-Turner]

Sounds good. I won't be surprised if we later get a complaint that the meaning of the square brackets is unclear...!

A

[pfmoore]

As noted on #84, that PR doesn't actually fix this.

I won't be surprised if we later get a complaint that the meaning of the square brackets is unclear...!

You already had it from me, on #84 🙂

If you want to close this again with an explicit rejection of the proposal that we don't show the w and -64 aliases at all in the install output, that's fine. I'll be sad, but I won't make a crusade out of it.