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.20:43:44
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1544215425.82.0.788709270274.issue34977@psf.upfronthosting.co.za>
In-reply-to
Content
Thanks Terry, great questions.

> I want this to be and remain an added alternative rather than a replacement of the current installer directly available on python.org.  Can you assure us that the latter are not going away?

Absolutely. The current installer is not going anywhere, and there's no point considering the possibility until we've completely dropped support for Windows 10 1803 and earlier (which was only released this year, so dropping support is a long way out yet).

> Installers are always experimental until tested by multiple users on multiple machines.  Even then, installation specific issues can arise. ...  To have a Windows Store Python ready for 3.8, we need to start now.

Thanks for the vote of support for this point.

> Steve, assuming that I can access the Store, should I be able to install both PSF 3.7.2 and Windows Store 3.7.2 simultaneously?  So I could test both IDLEs that beginners might install?

Yes, absolutely. (To be clear, both are PSF approved and under the PSF name/copyright/etc., so I've been calling them "traditional" and "Store" installers when I talk about them.)

Also, I've been testing IDLE regularly, since one of the advantages of being in the Store is that we can safely put idle[3[.7]].exe on PATH. It definitely works :)

I've also set up tests that run from an "installed" layout, rather than the source tree, and those are all passing as well (with one of the trivial test fixes in the PR).

> I am curious what 'restricted' versus 'non restricted' mean to Windows Store, and why Python can now go there.

In general, all app stores disallow their apps from doing things that may break or corrupt the machines they are installed on. Apps are self-contained and can only operate outside of their boundaries through carefully designed permissions/capabilities (which often prompt the user before continuing).

Recently, Microsoft added support for "full trust" apps, which can bypass many of these restrictions. The aim is to allow traditional applications to swap their MSIs for being installed through the store, which can then ensure trustworthiness of at least the installers. (For example, a Store app is *never* going to install something into System32 or modify operating system files, whether it's full trust or not.) Full trust allows us to do things like launching non-app store processes and creating raw sockets through legacy APIs, so we can very easily move Python into a full trust package rather than having to rewrite it using approved APIs (a project that's been attempted a few times, but always loses low-level functionality that is considered a core part of Python - hence my long-term desire to make the low-level parts optional and have higher-level abstractions be the guaranteed parts).

> While most PRs should be complete in themselves, reasons such as ease of review may suggest splitting one conceptual Pr into pieces.  They just have to be reviewed together, or with expectation of a needed followup (and a revert if it does not appear).  I have done this to get readable diffs for major refactorings that moved and edited multiple chunks of code in a large file.

I agree that it's valuable and I've done it internally plenty of times. Unfortunately, no matter how much people repeatedly say that a PR for CPython is part of a chain, there always seems to be pushback from people who ignore that and won't approve a critical prerequisite because there's "no need".

There's also the point that many of the changes were not known to be needed before the others were made. The pre-squash history is very interleaved between the various changes, and extracting them into separate PRs that totally stand alone is nearly as much work as solving the issues in the first place. I made the call this time to keep them all together and direct reviewers' attention towards the relevant parts. It turns out that didn't attract reviewers, so I'll come up with a new strategy next time I want to get people's attention on a change (maybe Buzzfeed style headlines? :) )
History
Date User Action Args
2018-12-07 20:43:46steve.dowersetrecipients: + steve.dower, terry.reedy, paul.moore, vinay.sajip, vstinner, tim.golden, ned.deily, zach.ware, xtreak
2018-12-07 20:43:45steve.dowersetmessageid: <1544215425.82.0.788709270274.issue34977@psf.upfronthosting.co.za>
2018-12-07 20:43:45steve.dowerlinkissue34977 messages
2018-12-07 20:43:44steve.dowercreate