[issue38905] venv python reports wrong sys.executable in a subprocess on Windows

[Eryk Sun]

Eryk Sun <eryksun at gmail.com> added the comment:

> the Store package, which can only be *executed* from outside its 
> container (we can't load the DLL directly).

The idea I was pondering was to create "python.exe" in the virtual environment as an appexec link to "C:\Program Files\WindowsApps\venvlauncher.exe" and reverse engineer whatever is needed to make CreateProcessW() build the required access token. For example, if it simply checks for the existence of "venvlauncher.exe" in the user's "WindowsApps" directory, then set that as an appexec alias as well.

However, it can't work for a simple reason. For an appexec link, CreateProcessW() reads and executes the target of the link. The original appexec link path is not retained, so there's no way for the "venvlauncher.exe" process to know about the virtual environment.

> PEP 582

"__pypackages__" doesn't seem like a drop-in replacement for virtual environments. The current directory (in the REPL) and script directory have always had precedence over the standard library, except in isolated mode, so "__pypackages__" seems more about providing a directory for Python packages that's neatly separated from the script directory. I presume also that "__pypackages__" would be added to sys.path even in isolated mode, though the PEP makes no mention of it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38905>
_______________________________________