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 vinay.sajip
Recipients ned.deily, ronaldoussoren, tdsmith, vinay.sajip
Date 2014-09-25.21:36:18
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> I consider using this undocumented environment variable in distlib
> as a bug in distlib, which should be fixed there.  

Well, let me explain why it's used: when Python >= 3.3 starts up, it looks for a pyvenv.cfg file proximate to sys.executable. If found, that means we're in a venv, and sys.path is set up accordingly. On OS X, the stub launcher is copied/symlinked to the venv when a new venv is created - the real interpreter is not copied. So, shebangs written by distlib into scripts installed into a venv must be of the form #!/path/to/venv/bin/python, and this cannot be obtained from sys.executable because that is pointing to a framework executable. There would be no pyvenv.cfg anywhere near that location.

This is why the __PYVENV_LAUNCHER__ variable was created, and distlib uses it because it needs to conform to how venvs work. In this respect distlib is a bit like setuptools - it needs to understand some low-level details which other libraries don't need to worry about.

Scripts installed in venvs work as expected (AFAICT) when used with stock Python framework builds on OS X. With HomeBrew, the complication appears to be caused by two levels of symlink: the executable in /usr/local/ points to one in /usr/local/Cellar/..., which in turn points to the framework executable.

The failing test (test_defaults) could be fixed by looking for equivalence in the "home =" directories in the test, rather than a string-contains-value test as at present.
Date User Action Args
2014-09-25 21:36:18vinay.sajipsetrecipients: + vinay.sajip, ronaldoussoren, ned.deily, tdsmith
2014-09-25 21:36:18vinay.sajipsetmessageid: <>
2014-09-25 21:36:18vinay.sajiplinkissue22490 messages
2014-09-25 21:36:18vinay.sajipcreate