It only breaks if people ignore all the notices about the upcoming change. Change breaks stuff, it’s inevitable, but plenty of stuff was already broken that is now fixed by this change.
We try to be as open about upcoming changes as possible, so people have time to adapt (only seven years left to adapt before there are no supported versions with legacy installers!), but the only way to preserve everything is for people to stop upgrading. We aren’t going to stop changing new versions so that people can get updates without having to change anything - that’s just not how updates work.
Our default settings configure double-click to open with py.exe. Have done since about 3.6. You’re welcome to configure your system differently, or to create an installer that configures things differently (we welcome more installers for people with special needs, we just aren’t going to build, maintain, support, host and distribute them all ourselves - Python has a very flexible OSS license that allows anyone to distribute their own installer).
Clearly you didn’t read the thread you replied to. Try reading from the start and you’ll find answers to these questions.
Are there plans to include debug binaries (pythond, python311_d.dll) to PythonTest or to some separate tag? I guess it’s the last advantage that classic installer has for me.
I’ve switched to PIM for all system Pythons I need occasionally, but I still use the classic installer for the main Python I use, since it provides debug binaries that I need to build and run some extensions in Debug configuration.
Btw, though --download advertised in the docs mainly as the tool to perform offline installations, I’ve found that it works really well for downloading Python just to build something, without creating any system footprint. I previously used nuget for this purpose, but now nuget seems inferior since it doesn’t have a package that has debug symbols, while PythonTest PIM tag does, though only for Python 3.11+.
No, there are too many external dependencies needed (specifically, you have to have installed all the dependencies you’d need to build it yourself, so we suggest just building yourself - then you’ll also have sources accessible for debugging CPython, which is the only reason you’d want debug binaries).
Depending on your build backend, you should be able to get it to build debug binaries for your extension while linking to a release CPython. If you aren’t planning to debug into CPython, this is just fine (arguably better) - as I said above, if you are planning to debug into CPython, better to build it yourself.
You mean --target? If so, then yes, this is one of the intended uses (though not as interesting as “downloading to bundle/embed”, IMHO, since eventually I’d hope build machines will just have what you need, or not be sensitive to user-wide installs, at which point a simple py exec -<version> ... to install/run on demand should be the norm).
As outlined, we would be distributing the manager via msix. However, the MSIX format can sometimes cause issues on some systems, so would it be possible to distribute exe installers as well for the manager? With something like inno setup or nsis, it would not be too hard. I would not mind maintaining it
You’re allowed to repack the official distribution as an executable installer, and distribute it either locally or publicly, if that’s what you are asking - the license allows you to do that. It’s just that the core devs won’t be doing so, as we don’t have the bandwidth to provide multiple installation packages (more precisely, to produce more than we currently do).
I could host it on something like gh releases in a repo I would make for bundling the msix into exe and we could link to it for the downloads page on python dot org. I could make a simple website too
That’s the bit that we wouldn’t do. You’re welcome to create and maintain such a distribution, but it wouldn’t be “official” and wouldn’t be supported by, or linked to from, python.org.
PyManager will auto-update itself if you use the MSIX (since that’s built into the OS). And you can run py install --update to update all installed runtimes - feel free to add a scheduled task to do that as frequently as you like (it won’t interfere with other management tasks, and it shouldn’t update a running interpreter, but that’s a bit of a heuristic with fairly obvious timing issues that are as mitigated as I can manage - it’ll try and update it next time).
Thanks, you can actually reference the appinstaller file from inside the MSIX since around 2022, and if you get it from the Store then updates are handled by the Store app. Our appinstaller files are here - the preview stream and release stream are separate, which may turn out to be a terrible idea, but so far it seems okay.
(I work at Microsoft and have collaborated closely with the team responsible for MSIX to make sure our installer for Python works well )
Also, since we are here anyway making a MSIX I think we should publish this to the Microsoft Store as well as the Python website. However, the PEP isn’t very clear on this. (That is my opinion, if anyone else has ideas, feel free to put them out )
Hello Steve
I have now used the new python manager for installing py 3.14.2 on my systems.
This has worked perfectly inclusive the removal of the old py.exe.
Thank you very much for your work and the pleasant user experience!
Might I give a short feedback regarding two minor issues?
There are a couple of questions where the user must make a decision: e.g. if the path length limitation shall be removed. My problem with questions like this is that I can’t easily see what is being recommended and what the consequences if I choose one option over the other. This could also be a challenge for beginners.
The py alias help does not show the pymanager commands which are available: e.g. “py list”. I would appreciate if the help “py -h” is extend or perhaps a reference to the pymanager help is added.
)
)