Well, I am very pleased to say that the work progresses well.
The new repo at GitHub - python/pymanager: The Python Install Manager (for Windows) is up and running. As I’ve mentioned a couple of times, it has the same permissions and CLA as the cpython repo, which means anyone is welcome to contribute, and core devs can merge and triagers can triage (and probably more helpfully, migrate issues). No obligation! But also no exclusion.
There’s also a first beta release available on our super-secret FTP pages (that get reported as security bugs once a month): Index of /ftp/python/pymanager/
if you had one of my previous releases, uninstall it first! (Your runtimes will still be there)
this package is using an index on python.org that currently only contains Python 3.5-3.9 and 3.14.0a{1,2,3,7}. I want to get some testing done before backfilling the rest of the releases (<=3.9 are not being backfilled, so they just refer to the NuGet packages)
the 3.14 releases now include IDLE! And all the Start menu shortcuts you’re used to
the size increased by about 20MB because the documentation is now included… not sure how I feel about that yet, thoughts/opinions welcome!
the Microsoft Store app will be published with the next version
versioning follows the date, so 25.0 will be the first release (see the repo readme for more info)
the MSIX will automatically update as new releases are made, so feel free to grab it and never worry about being up to date again
(One known issue if migrating from the earlier alpha is that an existing 3.14 install won’t be launched by the default tag. You’ll need to py install 3.14-dev --force to overwrite the old install.)
Thank you for all the work getting this done @steve.dower!
Do you have any rough idea of what the timeline would be to add 3.10-3.13 releases to the index? (Not trying to rush at all and appreciate the effort going into testing the releases, just wondering if that’s more like “next couple days” or “sometime in the next few weeks/months”)
And do you plan on doing it as one big add with all of them or adding each minor version as they are tested and built?
Next couple of days, I hope. We’ve already fixed a couple of issues in the script to generate the packages, so holding off has been justified (or they all would’ve been slightly broken), but once I’m confident that they’ll be created okay then I’ll go through and repackage them all.
It’ll be one big add, since there’s not really anything about the earlier releases that matters, just the script to generate new metadata for them. They’re not even being rebuilt, just repackaged - all files will be bit-for-bit identical to the original releases.
I notice there are two separate builds for python.org and for the MS Store. I’m wondering - does Microsoft not allow you to publish MSIX signed by whatever cert PSF uses and requires you to go through a different publishing process? The PEP says this, but I’m not entirely sure what that actually means:
The two builds are practically identical. The only difference between the MSIX we provide to the Store and the one that goes to python.org is package signing: we sign the python.org package ourselves, while the Store package is signed as part of the publish process. Otherwise, there is no additional cost to producing and publishing both packages.
On a somewhat related note, I prepared a first version of the Chocolatey package, which should mostly be fine, though I might need to write some additional logic for potential failure when the MS Store version is already installed. The error message should be decent, but it might be preferable to just detect that it’s there and not fail instead. I will have to play with it a bit more…
Interestingly, compared to the other way around, the error message on MS Store is not clear at all when you try to install Python Install Manager, while already having the python.org version installed
Yes, when you go through the store your package is actually checked by Microsoft before it gets published (not as thoroughly as they used to, but still more rigorously than we check our own). How much users care about that is based on who they trust more, but it’s the publishing process, and we don’t really have any ability to change it.
I was under the impression that the Store and the sideloaded version should either be fully detected or else work side-by-side (not that that’s particularly helpful). Again, unfortunately, outside of our control, so the best we can do is use Windows Feedback to file bugs against Windows. On the bright side, both the Store app and the App Installer app are separate from the base OS, so it’s much more likely that fixes will be made and distributed quickly.
If you’re using PowerShell for this, Get-AppxPackage PythonSoftwareFoundation.PythonManager should return the package regardless of how it was installed. The Publisher attribute on the result will be different, but that should be about it.
Yep, I’m using that for detection but, if the installed version is older, I currently install newer version without uninstalling the older version first. This works fine when the old version is from python.org but might run into problems, if the old version is from MS Store.
I haven’t actually tested whether such problem exists for upgrades yet, but definitely will at some point.
Yeah, I’m also interested to see how it goes, but it’s one of these things that can only really be tested at scale (installers are notorious for working well in controlled circumstances and failing miserably outside of that, for anyone reading who doesn’t spend as much time with them as Jakub and I do!)
The biggest problem is likely to be that auto-updates could break. Both Store and MSIX installs will support automatic updates, but through slightly different paths, and so changing from one to the other is probably only safe if it was deliberately planned for.
But since we already have auto-updates, and the aim is for the install manager to be versionless, I don’t think it’s at all inappropriate for Chocolately to just leave an existing install alone. If the user isn’t getting updates automatically, they’ve chosen that specifically. The critical case is going from zero installs to one, not from one install to the next.
Also, please publish a winget version. The store version is not enough. winget install 9NQ7512CXL7T looks ugly. It should look like winget install Python.PIM or something similar.
Anyone can submit WinGet packages if they want. We don’t want to support it, because WinGet doesn’t do package management and so it’s far too easy to corrupt your system. But I’m not planning on doing takedowns if other people put links in it.
Other tools will need to update, yes, but they need to update each year for new releases anyway. They won’t break on existing versions, but they’ll have to do more work to pick up 3.16 and later, rather than just flipping a version number.
uv doesn’t use our releases anyway, so they won’t be impacted.
Excuse me for the probably silly question that probably was already answered or it’s in the PEP (but I failed to find): the new Windows installation manager will have an executable that will open a GUI that will permit the user to install the version she/he desire, with all the other options that the current installer already have? Or the manager is a command-line only program?
Installing the install manager itself is a GUI provided by the operating system, but it has no options. So it’s just a file to double-click and then an “Install” button. After that, it’s all command line for actually managing Python installs - someone else might write a GUI at a later stage, but we’re not doing it ourselves right now.
Which options are you specifically thinking of?
Putting python and py on PATH is now always the case, handled by the OS installer, and adding all the python3.x.exe to PATH is optional after install. Each runtime will have its own entries for PATH that we can’t reliably manage, so if you aren’t using virtual environments and still want Scripts there, that’s a manual step (pip will prompt you to add the path when you install something).
File associations are automatic and will go through python rather than any particular install, so there’s no option required. Tests are excluded by default, but you can py install PythonTest\3.x to get a separate package that includes the stdlib test suite. Docs and IDLE are always included in the standard distro, so no option required. pip is always installed but doesn’t have a pip.exe, so you need python -m pip instead (we have an open discussion on the issue tracker about how to potentially enable this, but it’s not as simple as “just automatically update PATH for the user”).
No, I don’t think that’s the intention. As stated in the PEP, the old installers will be dropped by Python 3.16. The core devs have no plans to implement a GUI based setup dialog for the new installer - the CLI version is sufficient for most needs, and the extra maintenance cost of a GUI version[1] isn’t justifiable.
a large part of which is simply that most of the core devs don’t have Windows GUI coding skills, whereas anyone can code a CLI ↩︎
It’s more simple for users. This way the manager will be used only by expert users, and the majority of people will install Python from the Windows Store.
That’s kinda the point, except users[1] will install the manager from the Windows Store because that’s the only thing that will be available
Steve’s question is very relevant:
Note: that’s Python users, not users of applications written in Python. Generally, the latter users shouldn’t need to install Python on their own unless they’re also the former; applications that just happen to use Python should most likely be embedding their own Python interpreter ↩︎
MSIs are used for all sorts of purposes, such as enterprise distributions, and they integrate well into long established accessibility tooling, that I don’t understand how a CLI tool could fufil.
I don’t have a need for existing MSIs any more, so I’m not going to champion them, but I do think there should be more public awareness of this is really the case. Such as posting on the Python download site that these are deprecated and will be removed for Python 3.16(?).
The default download button will be replaced with an install manager download and a link to the deprecated installer once 3.14 releases and we make the whole thing stable.
There’s also a warning message in the 3.14 installer that it’s deprecated.
There’s also an entire section in the documentation for the install manager about admin/enterprise installs, an MSI with the install manager specifically for enterprise deployment (legacy deployment, since MSIX has been around for a decade now and should be supported by anything up to date).
This is also all covered in the PEP and earlier in this thread, and as I’ve pointed out, will be on the website once the deprecation officially goes into effect (the 3.13 installer is not deprecated, it’s just in maintenance mode).
I hope that covers your concerns? If you know anyone who may be impacted, do let them know, but short of taking out paid advertisements there isn’t really much left.
