Steve Dower <steve.do...@python.org> added the comment:
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? :) ) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue34977> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
