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 paul.moore
Recipients eric.smith, eryksun, paul.moore, steve.dower, tim.golden, uranusjr, zach.ware
Date 2019-11-25.11:51:12
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
I presume there's also the option of setting up the environment (or however it's done now - I know the details changed as the feature was developed) so that the "base" python.exe pretends to be the venv one, exactly as the wrapper does.

However, that may well have other difficult-to-fix implications, not least that calling the base Python using an explicit full path should act like the base Python, and *not* like the venv one.

IMO, the key thing here is that either the various limitations/quirks of redirecting to the base Python should either be treated as bugs, or they should be documented (even if only in the form of explicitly saying not to rely on any specific behaviour - e.g. "running an unqualified python and expecting a PATH search to pick up the same executable as the parent shell would is not supported and may produce unexpected results").

Virtual environments are a key part of most Python development workflows, and virtualenv is in the process of switching to use the core venv module internally. When that happens, there will be a lot more visibility for unexpected behaviours like this one.
Date User Action Args
2019-11-25 11:51:12paul.mooresetrecipients: + paul.moore, eric.smith, tim.golden, zach.ware, eryksun, steve.dower, uranusjr
2019-11-25 11:51:12paul.mooresetmessageid: <>
2019-11-25 11:51:12paul.moorelinkissue38905 messages
2019-11-25 11:51:12paul.moorecreate