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 eryksun
Recipients Benedek Rácz, Jurko.Gospodnetić, awaizman, eric.smith, eryksun, nirvana-msu, nsmcan, paul.moore, steve.dower, tim.golden, uranusjr, zach.ware
Date 2021-03-29.22:13:28
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> 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.
Date User Action Args
2021-03-29 22:13:28eryksunsetrecipients: + eryksun, paul.moore, eric.smith, tim.golden, Jurko.Gospodnetić, zach.ware, steve.dower, uranusjr, Benedek Rácz, nsmcan, nirvana-msu, awaizman
2021-03-29 22:13:28eryksunsetmessageid: <>
2021-03-29 22:13:28eryksunlinkissue38905 messages
2021-03-29 22:13:28eryksuncreate