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 uranusjr
Recipients cosven, uranusjr, vinay.sajip
Date 2018-03-02.17:17:46
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1520011066.83.0.467229070634.issue30811@psf.upfronthosting.co.za>
In-reply-to
Content
@cosven you are correct! I made some additional observation while working on adding venv support to pew, in this thread: https://github.com/berdario/pew/pull/173. I’ll try to summarise below.

The root problem is indeed virtualenv’s custom site module, but even then it is possible for venv (or any tool built around it) to know where the “original” Python is, since virtualenv stores the old sys.prefix in sys.real_prefix. Unfortunately, however, this is not as useful as it seems. What we really want in this situation is sys.exec_prefix, which may or may not be the same as sys.prefix. I did manage to cobble together a hack, but it is by no means bullet-proof.

To actually deal with this problem, we will need to amend the site module provided by virtualenv, as you mentioned. But this still can’t “solve” it. Since the site module is vendored in the produced virtualenv, existing virtualenvs will stay broken even after we managed to upgrade the virtualenv installations.
History
Date User Action Args
2018-03-02 17:17:46uranusjrsetrecipients: + uranusjr, vinay.sajip, cosven
2018-03-02 17:17:46uranusjrsetmessageid: <1520011066.83.0.467229070634.issue30811@psf.upfronthosting.co.za>
2018-03-02 17:17:46uranusjrlinkissue30811 messages
2018-03-02 17:17:46uranusjrcreate