So I expect many are unlikely to realise, but when we distribute CPython on the Windows Store I’ve been releasing each version as its own app. The model of all app stores is that you don’t get to control installation, and so users (virtually) always have the latest version of an app and cannot install side-by-side copies. Due to how CPython’s compatibility works,[1] the only way to make things properly correct is to have a separate app for each major version (shown in the screenshot below).
Clearly, this is far from the least confusing way to give people Python (with the exception of people who already understand our release model and are quite happy to be able to choose which versions they get). So I’d like to propose a new app that includes the ability to install specific Python versions on demand (note, not proposing any changes at all to the regular installer - only to what users get from the Windows Store, which already has some subtle differences).
A significant constraint is that the vast majority of Store package installs come from people who have typed python
or python3
on a clean Windows machine. These are presumably users who know they want to run Python, but don’t know anything except that command. Anything we install from the Store has to replace these commands so that these users can re-run their command and be successful.[2] We also can’t modify PATH
automatically - users have to be taught to do that themselves.
So, my proposed interface is basically this: a single Python app that provides python.exe
and python3.exe
commands (as today), where the python
command is actually a launcher rather than the interpreter itself.
This launcher would have the following subcommands:
python run ...
- essentially the same aspy.exe ...
today,[3] and therun
is optional (as in, if no subcommand is specified, the rest of the command is passed directly to whichever real Python runtime is selected). If no suitable runtime is available, it gets downloaded automaticallypython install [version]
- manually acquire a particular versionpython list
- list installed versions/paths (with filters, JSON, etc.)python tool ...
- do a pipx-like operation using the current/latest runtimepython help ...
- get better help than just-?
, maybe search/link to doc pages?
[Edit]: Added python help
subcommand
Any other thing that looks like a subcommand would be treated as a script filename, as it is today, so it’s only these few commands that would change behaviour. It is very unusual on Windows to create scripts without the .py
extension, so I have no concerns about this change (also, python .\tool
is a very easy way to ensure you get the file .\tool
rather than the subcommand). The python3
command is interpreted like python run ...
and so other subcommands are not supported (and one day it will refuse to launch a Python 4, but those days are very far away still).
Worth re-noting here that I am not proposing any changes to the regular installer or the regular python.exe
you get when you build from source. This is only for a new Windows Store package, which can only really be installed manually by a user.
Because we can’t directly modify PATH
, users won’t get additional python3.13.exe
commands etc. when new versions are installed. However, because we’ll directly control the install (both python install
and python tool
), we can make them available in a single directory that users can add to their PATH
if they want.
Venv is still incredibly important, and the idea is for anything more complex than a simple script or basic interactive use, users will python -m venv ...
and activate that, giving them the usual interface and behaviours. All that’s changed is the command to create the venv in the first place.
There are a number of other technical choices that flow from here (e.g. where are the installs kept, etc.), but in the hope of keeping the discussion a little bit focused, I’m going to defer those. There’s more than enough in this much proposal to keep everyone busy for now.
So, thoughts on the proposed design?
python.exe
installed from the Store acts as a launcher/manager rather than direct to a specific runtimepython3.exe
installed from the Store acts as a launcher (but not a manager)- Specific runtimes are downloaded/extracted on demand/request
- All operations can go via
python.exe
, or the user can modify their ownPATH
to get more direct aliases python tool ...
subcommand for “just install and run this tool however”python -m venv ...
still recommended for serious users (i.e. practically everyone here)
Specifically, we cannot silently upgrade users from e.g. 3.13 to 3.14, which is how it would work if we only had a single app in the Store. (Edit: Added later due to discussion feedback) ↩︎
Guess it’s worth noting that Microsoft owns those pre-installed stub commands, and only point to a python-dev owned app out of respect. They could point it to their own app if they decide it’s better for users. ↩︎
Providing
py.exe
from this app doesn’t meet the “replace the stubs” constraint, but the entry point could be provided as well. It wouldn’t be the same as the currentpy.exe
though. ↩︎