From Python 3.7.1rc2 and 3.6.7rc2 now available for testing discussion topic (restricted to Committers):
the new Microsoft Store package … does not add the py.exe launcher
Why not?
1 Like
A combination of time/effort constraints and a question of “do we really need it”?
Due to platform limitations, the currenty py.exe code needs some major restructuring to be able to detect the new Store package (due to one minor caveat in how registry mirroring is handled, which I’m trying to just get fixed in the OS). So for starters, it doesn’t work.
Fixing this in the launcher requires making it aware of Store apps, which makes it incompatible with Windows 7 and so it can’t ship as the default. We could put it in the Store package, but then it’ll end up lower on PATH than the usual one, and so that doesn’t work either.
However, unlike the traditional installer, putting commands on PATH is actually reliable via the Store app. For years now we haven’t been putting regular Python on PATH by default (if you enabled it then you’ve opted into the weirdness, sorry) and if you’ve been following the defaults then now this one will behave correctly.
As a bonus, it was trivial to include python3 and python3.7 aliases, as well as aliases for pip and idle (with version number variants also). This makes using it more consistent with the majority of instructions out there, as all the python3 my_script.py commands now work just like on Linux.
If we figure out a reliable way to make the regular py.exe launcher work with old versions of Windows and also locate Store packages, we will. If fixing the OS means it can be discovered normally, even better. In either of these cases, we’ll simply add it to the package, since the equivalent regular py.exe will also work. If we end up having to have a special one, I’m hesitant to cause more confusion, and would honestly rather concede defeat and train people back to typing python3 just like they do everywhere else.
1 Like
The most likely reason here would be “to support registering the .py and .pyw extensions”. Running them via “python” would mean they didn’t respect shebang lines.
Thanks for the detailed explanation.
Just to share my perspective: py.exe launcher has been a huge help to me as it seems to be the best way to deal consistently and easily with most of the different Pythons. For me it just works and solved or massively simplified many messy confusing problems. I encouraged everyone I know to start using it and it has had only upsides. The only problem so far was that Anaconda Python doesn’t work with it. So I had to start recommending not using that. I guess I’ll have to recommend not using the Windows Store Python as well.
Yeah, there’s been an open bug to support PEP 514 fully for a while now, which would be able to detect Anaconda. We just haven’t had anyone to work on it. (Perhaps for you it “just works”, but many people have contributed a lot of their free time to make that happen.)
Right now I wouldn’t be encouraging everyone to switch to the store app either 
It’s the first release and things will likely change over time.
1 Like
This is a good point. The extensions can be registered (and in fact are), but there’s no shebang handling in Python itself. I hadn’t thought about it, but it’ll be interesting to see who else misses it and why.
I’ll add a note to the docs before 3.7.2 mentioning this difference as well.
1 Like
While it’s UNIX-only ATM, crates.io: Rust Package Registry could eventually be made to be cross-platform if I ever finish it and either I stay motivated enough to add Windows support or someone else comes along and contributes it. Not sure if bundling in the Store package would be problematic, though, thanks to it being maintained outside of the CPython repo.
2 Likes
Haha, yeah. Guess I should have checked the OP before referring to it 
1 Like
@steve.dower I think that installing the py launcher by default from the Microsoft Store would help create a consistent experience for Python users on Windows.
I started working on trying to improve the Windows installation experience for Poetry on Windows:
The main issue is what Python entry point can be relied on. I am thinking mostly about new users to Python and wanting a single command for them to copy and paste to install Poetry with.
Currently the command is documented as:
(Invoke-WebRequest -Uri https://install.python-poetry.org -UseBasicParsing).Content | python -
But this fails if the user uses the traditional installer from Python.org, because that does not put python in the PATH by default. It does, however, but py in the PATH by default, so one might think better documentation would be:
(Invoke-WebRequest -Uri https://install.python-poetry.org -UseBasicParsing).Content | py -
But then, sadly, if the user has installed Python through the Microsoft Store, python is in the PATH but not py 
.
We could add a note in the docs about both, but I think that adds a papercut for new users. Could py be included also from the Microsoft Store when someone installs Python from the Store? I find it to be a useful tool allow working with multiple Python installs.
Also, do you have any metrics on the percentage of downloads from Python.org vs Microsoft Store for Windows users? This would help us target the Poetry docs at the majority of users.
Thanks.
I’m actively (though slowly) trying to work out a better approach to handling multiple versions, including installation, that can work in both scenarios, which is why I’m deliberately leaving the status quo alone for now.
It’ll quite likely be a store-installable “py” of some sort, as Microsoft have requested that we don’t put so many packages in the store (doesn’t help the search and recommendation algorithms vs. having a single version), and adding “py” to the current packages would cause a fatal conflict.
So the papercut remains until we commit to a way forward. There are too many subtleties here, and any change is going to break some people, so I only want to do it once.
Right now, approx 95% of the downloads go through python.org. This could change drastically if we ever agree to link to the Store from the download page, or if the Store decides to promote one of our versions, but until that happens it’s majority traditional installer still.
2 Likes
Thanks for the status report and all the great work you do. Definitely understand there are layers of complication at play.
Right now, approx 95% of the downloads go through python.org.
That is great to know, and helps us decide how to target the majority of Windows users.