So I have a fix for 3.9 for this, I believe (involves making sys.base_executable configurable via PyConfig and overriding it and config->home when we know we're inside an app container).

For 3.8 I can apply the same fix and make sys.base_executable public, or keep it as sys._base_executable. Either way, it'll show up in PyConfig. (Victor - thoughts here? Should be a non-breaking change, right?)

For 3.7, I'm going to have to come up with a different fix, and possibly expose some new private API to be able to pass through the correct executable path.


Fundamentally, the problem is that Windows is going to start enforcing some ACLs that were previously not being enforced. In theory, when an application is deployed in an app package (as required through the Store), you are not supposed to be able to launch the executable directly. Instead, you should go through your current user's apps directory (C:\Users\name\AppData\Local\Microsoft\WindowsApps\<package family>, which contains only symlinks to the actual executables).

This has a very good advantage that the package family name does not change with new versions, while the full install path does. Currently, a behind-the-scenes update of Python will actually break environments when their "home" path is no longer correct.

However, it does mean that we need to start reporting a sys.executable that is not inside sys.prefix, and I'm not sure whether that is a good idea.

Looking at venv (+Vinay for confirmation here), it seems to treat "home" as "the directory containing the original Python binary" rather than "the directory containing the Python install". So in theory (and in my simple testing), using the sys.executable-not-in-prefix here is fine. But is that intentional?