This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author steve.dower
Recipients ned.deily, paul.moore, steve.dower, terry.reedy, tim.golden, vinay.sajip, vstinner, xtreak, zach.ware
Date 2018-12-07.21:40:09
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> The first thing I'll note is that I'm not aware of any documentation
> on the Windows Store installer, and how it works.

Right now, correct.

> How will the Windows Store install work alongside the PSF one?

It will go into PATH under the same names as on other platforms (python, python3, python3.7, and same for pip and idle). The Windows Store makes it possible to do this reliably, so it's just on by default (and configurable through OS-provided UI for selecting the app to respond to a certain name).

If you have already installed it traditionally and enabled the PATH modification, that will take precedence. So you'll get the MSI installed Python. If you've modified PATH by hand, it depends on where you put it.

> If I have PSF Python 3.7.1 and Store Python
> 3.7.2 simultaneously installed, which will py.exe -3.7 select? Can I
> influence it to choose the other one? Same question for 3rd party
> tools like "virtualenv -p 3.7"

Right now, py.exe will not detect it. This is an unavoidable limitation right now (specifically, enumeration of classic app compatibility keys does not work, though direct access does), but it may become avoidable in the future (and being able to say "Python needs it" is actually going to be useful for removing the limitation).

As usual, our recommended way to influence choice of Python is to specify it. "virtualenv -p 3.7" will find a traditionally installed Python first, but if it's not there and the store one is it *might* find the store one (it depends whether it requests the specific registry key or tries to enumerate all of them - again, I've got people looking into enabling enumeration, but we're talking about adding another feature to Windows specifically for Python, and those take time).

> Basically, I'm not clear on how having the Store install and the PSF
> install simultaneously present will work - very few tools in my
> experience really support PEP 514 (not even the `py` launcher) - and
> frankly, if we're going to break tool assumptions that there's only
> one official "3.7" present at any time, we're on very shaky ground
> claiming that PEP 514 warned them if we haven't even updated our own
> supplied tool! (I know that there's lots of ways people can have
> multiple versions right now - PSF plus Anaconda, for example - but
> it's fine to say "you're mixing distributions, you're on your own" in
> that case. If the PSF is publishing two versions of 3.7, which can be
> simultaneously installed, we can't really use that argument.

In all the cases I've tested, regular Python install shows up first. If it's not installed, the Store app shows up much of the time. This feels like the right design (with the caveat about "much of the time" requiring changes outside of our direct control), but without actually giving it to people in all their messy configurations there is literally no way to be sure.

A regular install does not create "python3" and "python3.7" shortcuts on PATH, so if you use those you'll prefer the store app. But we've never used those, so there shouldn't be any change to existing behaviour. And I've never really been opposed to adding them to the Python installer, I just haven't done the work (and neither has anyone else) - I'd still be opposed to modifying PATH from the traditional installer though, as all of those problems remain.
Date User Action Args
2018-12-07 21:40:09steve.dowersetrecipients: + steve.dower, terry.reedy, paul.moore, vinay.sajip, vstinner, tim.golden, ned.deily, zach.ware, xtreak
2018-12-07 21:40:09steve.dowersetmessageid: <>
2018-12-07 21:40:09steve.dowerlinkissue34977 messages
2018-12-07 21:40:09steve.dowercreate