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.
Yeah, I agree, but the only good alternative here is to not offer the option at all. We can’t print more text and make it more obvious, and it isn’t actually our (Python’s) setting to mess with anyway, so we can’t really go documenting it in detail.
Uh, sure it does? That’s all that py help shows? What command are you running? (Note that py --help triggers Python help, not PyManager’s help, and this is by design (the design of the old launcher) and preserved by request (see the earlier discussion around this PEP))
Ah, I see, thanks for the tips!
Here we have a disadvantage of the one program to rule them all.
I have used “py -h” and was not able to find the “py help” variant with the pymanager commands.
It might be an idea to mention “py help” in the “py -h” output so that this can be discovered.
There is another minor quirk: “pymanager -h” and “pymanager /?” signal an error (and luckily print also the help) albeit “-h” and “/?” are usual options to access the help.
We can only do this at the very top of the output, which will likely scroll off the screen. “We” don’t control the -h output, because it’s the exact equivalent of py -V:default -h[1]. The -h is for the selected runtime.
Could be filed at GitHub - python/pymanager: The Python Install Manager (for Windows) as a feature request, but as you say, it already prints the help in that case. So really, all we’d be changing is making the “error: invalid option” message into a “warning: not a valid option, but we know what you meant this time” message.
Off the top of my head, -V:default may not work, but it’s the intent. py -V:3 is close enough for most users, but not strictly correct. ↩︎
Hm, I feel like the point here was missed. The options presented at install aren’t all necessarily problematic for lack of detail, but for not being clear. For questions like:
Windows is not configured to allow paths longer than 260 characters.
…
Update setting now? [y/N]
In plain English, what the user is being asked is not to “update” a setting but to change one. “Update setting now?” doesn’t make it clear what you’re asking them to do. A more clear question would be something like “Enable long paths now? [y/n]”
For another one:
Install the current latest version of CPython?
The average beginner wants Python and has no idea what CPython is. If part of the goal here is to make things more beginner friendly, it should probably just be called Python if you don’t want to explain what CPython is (see the “old” installer).
On a separate line of thought, I find Python installed through the Python Install Manager to be finnicky in some annoying ways. I suspect some of this is that I’m used to just being able to install everything in the Programs directory with administrative privileges, whereas now Python wants to put things in appdata and pip wants to put things in localappdata and I’m having to add more to environmental variables than I used to just to get things to run.
For an example of finnickiness, why has the behavior of os.getcwd() changed when Python installed is through the Python Install Manager?
When installed the old fashioned way, os.getcwd() returns the directory where the script resides in all normal cases.
When installed the new way, os.getcwd() returns the directory where the script resides if you call it from IDLE…BUT os.getcwd() returns C:\Windows\System32 every time if you run the script in the terminal by double clicking on it…UNLESS you generate an executable (e.g. with pyinstaller) in which case it behaves like it used to.
Now I need to use “_file_” to find out my script’s location in order to work with neighboring files, but not while I’m in an IDE, just if I try to use it outside of an IDE… UNLESS you generate an executable (e.g. with pyinstaller) in which case “_file_” just directs you to a temporary folder so you have to go back to doing things the old way…
It’s just confusing and inconsistent for no reason I can see, whereas the “old” exe installer results in a perfectly well-behaved interpreter. I’m assuming this has something to do with restrictions on the appdata directories but it’s very disappointing.
)
)