Good. They’ll get the install manager, run python, and get the latest version of Python, just like they’re intending to do today.
I strongly suggest you read the PEP and the documentation, since we’ve clearly thought about things that you’re worried are new. After you’ve had a read, and maybe actually tried out the install manager, do come back with informed feedback.
Yes, but with a header that indicates it is deprecated and a clear visual warning box. To me, the visual language of that screenshot is that it’s a miscellaneous note that users are unlikely to ever read.
As I say, I no longer rely on the MSIs, so I’ll take it on good faith for you that MSIXs have wide ecosystem support, and are user friendly to users who have no CLI experience (keep in mind many users that install Python do so as a prerequisite for an application or tool, not that they are a developer or have ever used a CLI in their life).
But if users, especially those relying on accessibility software, find problems with the MSIXs I hope that there is a consideration to delay deprecating the MSIs
Funnily enough, I’ve recently been helping out a number of teams migrate to MSIX because MSI is so bad with accessibility software.
I appreciate that you’re trying to find flaws, but I’ll wait until we start hearing about real issues before making changes to the already agreed upon plans.
I had it in my head that the Python MSIX installers would also go on Download Python | Python.org in place of the old school MSIs although I can’t find any reference to that. Did I just imagine it?
If they were copied onto there, that would provide the download installer, click on installer, click yes experience that most Windows users are used to (assuming we still need it).
Already on the Windows page: Python Releases for Windows | Python.org
Should be at the top of the page you linked when 3.14 releases and you’re detected to be on a Windows machine.
There’s only one MSIX installer for all time, now, just to install the manager. Each release page will link to an install manifest for that particular version (e.g. Python Release Python 3.14.0b3 | Python.org) which lists all the ZIP packages, their URLs and hashes (and can be used with py install --source <URL> <version> if you really want), but the recommendation will be to py install <version> or py install --upgrade to install new releases. No need to visit the site to download updates manually anymore.
Side note: for non-Windows experts like me, it is possible to explicitly recommend one of these options in the download page (install manager vs. MSIX installer vs. MSI package).
As an extra (but that might also make things more confusing for the casual downloader), linking to advanced instructions for each format would be nice as well. By advanced instructions, I mean something like “the XXX format will by default provide an installation GUI with options Foo/Bar, but you can also execute it from the command-line with options --foo and --bar”.
Does the current text cover it? We certainly try pretty hard to recommend the Store app over the MSIX over the MSI, though not quite to the point of “if you think you want the MSI you’re probably wrong” (though I have told people that in issue reports).
Perhaps it isn’t clear enough that there’s only the install manager? And once the deprecation period ends there won’t be any direct downloads for each individual release anymore? (The main reason for listing that JSON file is because if there are no download files, there’s no download page, and that’s just a bit too confusing IMHO.)
The specific text on the download page that I think covers this is:
Full documentation for the Python install manager is available in our documentation. In particular, there are troubleshooting guides, as well as instructions around administrative installs, including intended use of the legacy MSI installer. Use of the Store app or the MSIX package is recommended.
I had no directly experience with Windows Store, but one of my coworkers had installed Python from it. I suggested him to install and run Jupyter, but he said it didn’t worked. I tried on his machine and indeed it didn’t worked.
He is a newbie, so probably did something wrong, I don’t know. Anyway, I suggested him to uninstall the Windows Store installation and get the installer from python.org, and it worked.
I don’t want to say Windows Store is flawed, but IMHO the good old installer should not so hard to continue to maintain, and can offer an alternative and official way to get Python for Windows for newbies.
What if, for example, the company block the use of Windows Store and of any Python installer with a signed certificate? My company does not block Windows Store, but unsigned Python installer yes.
How long ago was this? The Windows store Python had some pretty horrendous issues [1] a few years ago which don’t exist anymore.
packages were blocked from even reading their own resources ↩︎
Good question, let’s see my CV X-D
Ok, it was in 2021. I hope this problem was gone away. Anyway, I want to reaffirm, I don’t know for sure it was a problem of Windows Store or it was my coworker that did something wrong.
I don’t find the useful information easy to make out of it:
Since there are several options, there should really be a list or table of each option’s pros and cons (why would I use one over the other), and which one is/are deprecated.
It’s not clear at all actually.
I see you publish MD5 checksums.
I would expect SHA checksums as MD5 is nolonger considered secure.
I dont think it’s necessary (but would still support swapping that to sha256), md5 is “fine” for non-adversarial contexts and just ensuring it downloaded properly, and the installer itself is signed through the mechanisms included in the MSIX format.
You can check this with the following bit of powershell (there’s more you can do here, especially if you’re expecting a specific signer)
Get-AuthenticodeSignature .\python-manager-25.0b11.msix
Just cut off any trivia attempt by a bad actor to hack python.
The use of MD5 checksums isn’t something unique to the new installation manager so I’d consider it a separate issue.
For example all of the downloads for the 3.13.5 release on python.org have MD5 checksums.
Yeah, the problem here is that packaged apps are designed to be safe to use without worrying about them corrupting your machine, which implies they can’t do certain things (such as sharing files with other apps in hidden directories). Some Python programs (such as Jupyter) relied on this behaviour, (others on things like modifying PATH to change which DLLs get loaded). There were pretty easy ways for apps to change their behaviour to work around these issues, but most never made them.
However, the install manager’s runtimes are not packaged apps, so they will run without restriction (for better or worse). The install manager itself is, but it’s not extensible and isn’t used for anything other than installing/uninstalling runtimes, and so shouldn’t face the same issues. This is something that was considered, discussed, and written up in the PEP.
Make a PR to GitHub - python/pythondotorg: Source code for python.org to update the entire website, there’s currently no field for a SHA256.
In any case, the installers are signed with proper cryptographic signatures, so anyone actually running them will get real validation that can’t be hacked like an MD5.
I do really appreciate this feedback, and want to dig a bit deeper to make sure I understand it (probably won’t be able to fix anything for the next few weeks while I’m travelling, but others have the power/permission to do it if it’ll help).
Which options are you thinking of here? The page with that text only lists two downloadable files, but your dot points aren’t referring to both of those, so I’m guessing you’re treating the choice as “between the downloads on this page and the downloads on a different page”?
For Windows, at least, all the downloads on other pages (from 3.14) are deprecated and will not be there from 3.16 (the JSON file that’s only just started appearing will remain, but that isn’t a direct installer - it’s more of a public record of the packages associated with that release). So for anyone who’s already on the install manager download page, the advice would be “download from here and not from anywhere else”. Does that answer the pros/cons question for that aspect?
For MSIX vs. MSI (the two choices on the install manager download page), the intended decision is “does my distribution installation system refuse to support MSIX” (as per the first paragraphs of the docs here, which may deserve to be brought directly onto that page for early releases):
For situations where an MSIX cannot be installed, such as some older administrative distribution platforms, there is an MSI available from the python.org downloads page. This MSI has no user interface, and can only perform per-machine installs to its default location in Program Files. It will attempt to modify the system
PATHenvironment variable to include this install location, but be sure to validate this on your configuration.
Does this text provide the information you need? Or do we need to be more opinionated and basically say “don’t use the MSI until you’re sure you can’t use the MSIX”?
On this one specifically, the answer is yes for some casual uses of “MSI”, but I’ve used “traditional executable installer” to be more specific. The current installer is an .exe file, not an .msi, but it used to be an .msi (3.4 and earlier) and the .exe contains a number of .msis, so it’s technically accurate, but probably not that helpful.
The main thing I want to imply here is “the native installer that installs one particular version of CPython”, as opposed to a “dumb” package that contains one particular version, or the installer for the install manager, which provides all versions. Would love to understand which point is key here to help clarify the difference.
Noted. I suspect most people will discover this from the message in the deprecated installer itself, which will hopefully be the right context, but we can probably amp up the labelling on the 3.14/3.15 release pages to indicate that they’re all going to stop being delivered. However, many people assume “deprecated” means “must stop using immediately”, which isn’t the case, and I’m a little worried about causing undue fear by making it seem that way. Tricky balancing act, so it might just be that increasing the labelling for 3.15 is the right time to do it. Again, interested in any specific thoughts or ideas you have here, if only to help make sure I understand what’s needed better.
Well, I was looking at the Windows downloads page.
Kind of, but that should probably be mentioned clearly on other pages as well? Or perhaps all pages should prominently link to an explanation document?
I think a more opinionated statement would be good indeed!