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 chrullrich, davin, eryksun, ned.deily, paul.moore, pitrou, steve.dower, tim.golden, zach.ware
Date 2019-01-21.17:46:08
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1548092768.81.0.395902756265.issue35797@roundup.psfhosted.org>
In-reply-to
Content
You can't create symlinks on Windows without additional user permissions, and the old method of copying most of the binaries was slow and made DLL hell worse, as well as simply not working with the Windows Store model that does not let random executables load DLLs from within the app.

Because of the last one, I backported the fix (which is an independent executable that launches the correct one with additional context to know it's a venv) that was mostly there for 3.8 already. This also fixes the issue where upgrading Python would force you to recreate every virtual environment to avoid mismatched binary versions (which is also why it wasn't an incompatible change - the update was already incompatible).

So all in all, an overall positive change. It's unfortunate that this problem slipped through testing, and I assume it's going to exist for many cases using handle inheritance. When I get a chance I'll be looking up ways to simply flag the new Python process it creates as "inherit everything", but there may be other data structures that don't transfer automatically (such as file descriptors, which the OS knows nothing about and can't do automatically).
History
Date User Action Args
2019-01-21 17:46:09steve.dowersetrecipients: + steve.dower, paul.moore, pitrou, tim.golden, ned.deily, zach.ware, eryksun, chrullrich, davin
2019-01-21 17:46:08steve.dowersetmessageid: <1548092768.81.0.395902756265.issue35797@roundup.psfhosted.org>
2019-01-21 17:46:08steve.dowerlinkissue35797 messages
2019-01-21 17:46:08steve.dowercreate