[Python-Dev] Python install layout and the PATH on win32

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