[Python-Dev] Python install layout and the PATH on win32 (original) (raw)

Carl Meyer carl at oddbird.net
Fri Mar 16 00:48:30 CET 2012

On 03/15/2012 04:19 PM, Mark Hammond wrote:

On 16/03/2012 8:57 AM, VanL wrote:

On 3/14/2012 6:30 PM, Mark Hammond wrote:

So why not just standardize on that new layout for virtualenvs? That sounds like the worst of all worlds - keep all the existing special cases, and add one. I'm not so sure. My concern is that this will break external tools that attempt to locate the python executable from an installed directory. However, I'm not sure this requirement exists for virtual environments - such tools probably will not attempt to locate the executable in a virtual env as there is no standard place for a virtual env to live. So having a standard layout in the virtual envs still seems a win - we keep the inconsistency in the layout of the "installed" Python, but tools which work with virtualenvs still get a standardized layout.

The implementation of virtualenv (and especially PEP 405 pyvenv) are largely based around making sure that the internal layout of a virtualenv is identical to the layout of an installed Python on that same platform, to avoid any need to special-case virtualenvs in distutils. The one exception to this is the location of the python binary itself in Windows virtualenvs; we do place it inside Scripts\ so that the virtualenv can be "activated" by adding only a single path to the shell PATH. But I would be opposed to any additional special-casing of the internal layout of a virtualenv that would require tools installing software inside virtualenv to use a different install scheme than when installing to a system Python.

In other words, I would much rather that tools have to understand a different layout between Windows virtualenvs and Unixy virtualenvs (because most tools don't have to care anyway, distutils just takes care of it, and to the extent they do have to care, they have to adjust anyway in order to work with installed Pythons) than that they have to understand a different layout between virtualenv and non- on the same platform. To as great an extent as possible, tools shouldn't have to care whether they are dealing with a virtualenv.

A consistent layout all around would certainly be nice, but I'm not venturing any opinion on whether it's worth the backwards incompatibility.

Carl

-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: <http://mail.python.org/pipermail/python-dev/attachments/20120315/9556a8aa/attachment.pgp>

More information about the Python-Dev mailing list