PEP 773: A Python Installation Manager for Windows

steve.dower · 2025-04-24T10:54:42.394Z

David Ellis:

Ah, my thinking was that the ones listed under ‘commands’ were the ones that it would make sense to switch, as none of those work under the old py launcher.

Well, no, because the idea is that users won’t have the old py launcher, and so all the commands will work. That may not be true for the transition period, but every time someone sets up a clean machine, they’ll only have the py with the commands, and eventually that’ll be everyone.

And if they update the old launcher and start getting warnings for those commands telling them to uninstall it, some percentage are going to uninstall it and they’ll also have all the commands in one place. Sooner than “nobody has the old one” we’ll reach a point where people have the old one by (hopefully informed) choice, and so have no reason to complain that the help text for a different program is telling them about features they’ve chosen not to get.

In any case, I’ve updated it (not released yet) to show the name of the command that was invoked in both places.

DavidCEllis · 2025-04-24T11:33:42.566Z

Steve Dower:

DavidCEllis:

Ah, my thinking was that the ones listed under ‘commands’ were the ones that it would make sense to switch, as none of those work under the old py launcher.

Well, no, because the idea is that users won’t have the old py launcher, and so all the commands will work. That may not be true for the transition period, but every time someone sets up a clean machine, they’ll only have the py with the commands, and eventually that’ll be everyone.

Yes that’s the goal, but while things are switching over the commands that you originally did change are those that would work with both versions of py, while the ones you didn’t are the ones that won’t work with the old py.

Steve Dower:

In any case, I’ve updated it (not released yet) to show the name of the command that was invoked in both places.

I think the cross-platform/Linux discussion doesn’t really belong in this thread but I have noted that some distributions appear to be providing uv now, which has its own Python install managing behaviour and I don’t believe they’re disabling that^[1] so I don’t think it’s completely out of the question^[2].

Although they may be modifying the defaults to stop it installing runtimes automatically ↩︎
As long as it doesn’t interfere with the Python relied on by system utilities ↩︎

pitrou · 2025-04-24T11:42:24.846Z

As an amusing sidenote, Ubuntu 24.04 does provide a package that installs an unrelated py command:

$ py
La commande « py » n'a pas été trouvée, mais peut être installée avec :
sudo apt install pythonpy

$ apt show pythonpy
Package: pythonpy
Version: 0.4.11b-3.1
Priority: optional
Section: universe/utils
Origin: Ubuntu
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Original-Maintainer: Tiago Ilieve <tiago.myhro@gmail.com>
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Installed-Size: 49,2 kB
Depends: python3:any
Suggests: bash-completion
Homepage: https://github.com/Russell91/pythonpy
Download-Size: 10,2 kB
APT-Sources: http://archive.ubuntu.com/ubuntu noble/universe amd64 Packages
Description: 'python -c', with tab completion and shorthand
 pythonpy is an utility that facilitates the usage of Python one-liners. The
 command 'py' evaluates a string consisting of any Python expression. It can do
 anything from simple arithmetic to complex operations, importing modules
 automatically. It also comes with tab completion.
 .
 Its usage is not restricted to single expressions only. There's also the
 possibility to pipe data from stdin and to stdout, even generating strings to
 be evaluated by other programs.

And then:

$ sudo apt install pythonpy
[...]

$ py --help
/usr/bin/py:29: SyntaxWarning: invalid escape sequence '\.'
  if re.match('np(\..*)?$', raw_module_name):
/usr/bin/py:31: SyntaxWarning: invalid escape sequence '\.'
  elif re.match('pd(\..*)?$', raw_module_name):
usage: py [-x] [-l] [-c PRE_CMD] [-C POST_CMD] [-V] [-h] [expression]

positional arguments:
  expression     e.g. py '2 ** 32'

Options:
  -x             treat each row of stdin as x
  -l             treat list of stdin as l
  -c PRE_CMD     run code before expression
  -C POST_CMD    run code after expression
  -V, --version  version info
  -h, --help     show this help message and exit

$ py '2 ** 32'
/usr/bin/py:29: SyntaxWarning: invalid escape sequence '\.'
  if re.match('np(\..*)?$', raw_module_name):
/usr/bin/py:31: SyntaxWarning: invalid escape sequence '\.'
  elif re.match('pd(\..*)?$', raw_module_name):
4294967296

That’s even though the upstream repository doesn’t exist anymore.

brettcannon · 2025-04-24T18:37:34.864Z

Antoine Pitrou:

Ubuntu 24.04 does provide a package that installs an unrelated py command:

Yeah, it’s why the Python Launcher for Unix is usually packaged under “python-launcher”.

merwok · 2025-04-24T19:17:53.560Z

Sure, but is the executable name py? If yes then the two packages have a conflict.

steve.dower · 2025-04-24T19:21:16.370Z

If there’s an actual suggestion that we should reject this PEP on Windows because an old project on Linux uses the same command name, then by all means, keep discussing it.

If not, it’s off topic. Please start a new thread.

(For completeness, “do the same thing on all platforms” is under Rejected Ideas in the PEP as a deferred idea - we’re not doing it now, but we’re not ruling it out in the future.)

pitrou · 2025-04-24T19:25:39.829Z

Steve Dower:

If not, it’s off topic. Please start a new thread.

I’m not the one who started discussing Linux distributions. And as I said:

Antoine Pitrou:

As an amusing sidenote […]

steve.dower · 2025-04-25T14:43:05.122Z

I’ve put up the PRs I intend to merge assuming the acceptance happens (since I’m planning/hoping to be off the computer for the weekend, so giving people who aren’t or who are in a different time zone a chance to review):

changes to cpython repo (primarily deprecation and docs, also support for python PC/layout --preset-pymanager which is used by the release build)
changes to release-tools repo (adding support to the release build/publish, and also doing a well overdue cleanup of the pipelines)
changes to pythondotorg repo (trying my best to update our website, but I would love any help here! This one probably gets split before merging, I expect, and gets dealt with last)
full pymanager repo which I’m intending to have imported under github.com/python, with all core devs having permission to merge (just like cpython) and all triagers having permission to triage (and with a bit of luck, the same CLA as cpython). There’s a few more changes required to make it right (new URLs in places, for example), but otherwise it’s ready for migration

barry · 2025-04-25T20:36:18.989Z

Barry Warsaw:

We intend to accept PEP 773 on Friday, April 25, unless someone can give us good reason not to.

As no reason has been given and here we are, the Steering Council officially accepts PEP 773! Congratulations and thanks @steve.dower and everyone else who has contributed to a great discussion.

steve.dower · 2025-04-28T22:47:31.278Z

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.)

jamesdow21 · 2025-04-29T16:16:15.256Z

Steve Dower:

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)

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?

Thank you again and really happy to see this!

steve.dower · 2025-04-29T16:20:54.871Z

James Dow:

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”)

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.

jack1142 · 2025-05-02T23:58:10.532Z

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

image769×475 21.7 KB

steve.dower · 2025-05-05T15:15:51.377Z

Jakub Kuczys:

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?

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.

Jakub Kuczys:

it might be preferable to just detect that it’s there and not fail instead

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.

jack1142 · 2025-05-05T16:33:41.381Z

Steve Dower:

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.

steve.dower · 2025-05-05T16:38:00.208Z

Jakub Kuczys:

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.

kneelesh48 · 2025-05-29T14:06:46.288Z

This post was flagged by the community and is temporarily hidden.

kneelesh48 · 2025-05-29T14:12:49.208Z

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.

kneelesh48 · 2025-05-29T14:34:36.462Z

Would not publishing python binaries break tools like winget install, choco install and uv python install?

steve.dower · 2025-05-29T14:36:44.088Z

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.