Python install manager 26.0 beta 1

Core Development
1

Today we’ve released the first beta of the next install manager update.

There is one major change in this version, and I would really like to hear some people making use of it before rolling it out to all users. Other changes are fairly minor.

First, minor changes

  • authenticated proxy servers should now auto-logon when the OS knows the credentials
  • shebang lines in scripts may now choose the version for automatic installs (e.g. if you py exec my-script.py and it contains #! python3.13 but you don’t have 3.13 installed)
  • shebang lines won’t cause pyw/pythonw windowed launchers to pop up consoles (e.g. if you didn’t specify #! pythonw as the shebang)

Script entry points

One of the biggest gaps with the initial release was that each installed runtime would not be added to PATH. This is fine for the main install directory, which only ever contained python[w].exe, because we have a central directory that gets generated shortcuts for all installed versions (correctly ordered, etc.).

However, it mattered a lot for the Scripts directory, which contains executables generated by pip or other installers that do global installs. Most notably, pip.exe would not be globally available after installing a runtime, and even though we recommend people use virtual environments rather than global installs,[1] it still caused quite a bit of upset.

Not wanting to prioritise pip over other tools, we now generate launcher executables for all detected entry_points.txt files in .dist-info directories under known package install directories. The first two parts following the packaging specification, and the latter has been added as a field in the feed, defaulting to Lib\site-packages and Scripts (which covers regular CPython for all existing releases).

In short, the py install --refresh step now generates pip.exe and similar for all installed packages that register an entry point. This step runs automatically after runtime installation, but does not run after package installation (installers could choose to run it if they want). For now, after installing a new global command, users will have to run py install --refresh themselves.

The launchers are created following the same order as interpreter aliases, so if two installs have the same command then you get a consistent (and hopefully obvious) result. They all go in the same directory as the versioned commands, which we offer to add to PATH for you and regularly warn if it’s not there. We still recommend py -V:<version> -m command ... to launch all of these, particularly if users need to be sure which one is going to run. But by making the basic command more accessible, we hope to reduce complaints and at least satisfy simple cases (one installed runtime, no venv).

But as you can tell from the length of my explanation, there are some tricky moving parts here. Any testing would be greatly appreciated - replace your install with the beta linked above (or if you’ve installed a previous beta, you should get this one automatically within a day or so). I’d especially like to hear some positive “works for me” comments, as well as any issues (either here on on the tracker).

  1. Which work fine, incidentally, because activating a venv puts its own Scripts directory on PATH. ↩︎

5 Likes
2

Is it possible to request that the launcher not install shortcuts for entry points? I wouldn’t typically want entry point executables (because I have a global copy of the pip zipapp on my path, among other reasons) but I am interested in having the (versioned) python executables.

I appreciate that I’m going to be in a minority here, and if this isn’t possible I’ll likely just not use the shortcuts at all, but I do think it’s a valid choice for people to want to make.

4 Likes
3

I don’t want them either if I can avoid them.

4

Uh, there was, but I refactored to make things simpler and it went away. Will add a config setting.

1 Like
5

Whenever I run py or pymanager from bash this popup momentarily appears.

image
image1920×865 261 KB

And I can’t get anything in ~\AppData\Local\Python\bin to work. Does this make any sense to you?

C:\Users\bagpuss>pymanager
Python installation manager 26.0b1
... We could do with a proper version command ...

C:\Users\bagpuss>where python
C:\Users\bagpuss\AppData\Local\Python\bin\python.exe
C:\Users\bagpuss\AppData\Local\Microsoft\WindowsApps\python.exe
C:\Users\bagpuss\AppData\Local\Programs\Python\Python312\python.exe

C:\Users\bagpuss>python
Access is denied.

C:\Users\bagpuss>C:\Users\bagpuss\AppData\Local\Python\bin\python.exe
[ Creates an error popup saying We can't open this 'ms-store-link'; Your device needs a new app to open this link. ]

C:\Users\bagpuss>pymanager install --refresh
Refreshing install registrations.
[WARNING] An existing runtime is registered at PythonCore\3.12 in the registry, and so the new one has not been registered.
This may prevent some other applications from detecting the new installation, although 'py -V:...' will work. To register the new installation, remove the existing runtime and then run 'py install --refresh'
Python 3.14.2 will be launched by python.exe and also python3[-64].exe, python3.14[-64].exe
Python 3.13.1 will be launched by python3.13.exe
Python 3.12.8 will be launched by python3.12.exe
Python 3.11.9 will be launched by python3.11.exe
Python 3.11.9 (ARM64) will be launched by python3-arm64.exe, python3.11-arm64.exe

C:\Users\bagpuss>C:\Users\bagpuss\AppData\Local\Python\bin\python.exe
[ Same error popup ]

C:\Users\bagpuss>C:\Users\bagpuss\AppData\Local\Microsoft\WindowsApps\python.exe
[ Same error popup ]

C:\Users\bagpuss>where py
C:\Users\bagpuss\AppData\Local\Microsoft\WindowsApps\py.exe

C:\Users\bagpuss>py
[ This behaves as expected ]

C:\Users\bagpuss>C:\Users\bagpuss\AppData\Local\Python\pythoncore-3.14-64\python.exe
[ This behaves as expected ]
1 Like
6

This sounds like this known issue, which is caused by being on a metered network (it’s an OS bug that’s been fixed, we’re just waiting for that fix to roll out in updates). You should be able to confirm by using a non-metered network (this is a configuration setting under your control) and launching - if the dialog doesn’t pop up, then you should get the fix in the near future.

Hmm… this is quite surprising.

ms-windows-store:// should be handled by the Store app, so if you’ve disabled, removed, corrupted, or otherwise broken that, it might be the problem. I’m not sure how you do any of those (besides disabling), but just trying to launch the Store app might provide a hint. (I assume it says ms-windows-store rather than ms-store-link, since the latter doesn’t exist… if it does say the latter, you’ve got unrelated system issues, sorry!)

But in any case, we shouldn’t be trying to launch a Store link from our install manager executables. My guess is that we’ve somehow put the path to the preinstalled python.exe into C:\Users\bagpuss\AppData\Local\Python\bin\python.exe.__target__ (which you can easily check by looking in that file), but I can’t think of any ways for that to happen naturally.

It’s possible the py install --refresh logs (or -vv output) may have a hint - could you file an issue and include the log for that? And also the py list -f json output. (These may include usernames or personal information from your system, feel free to scan and censor before posting them.) Thanks!