[Python-Dev] draft PEP: virtual environments

Carl Meyer carl at oddbird.net
Mon Oct 31 15:06:26 CET 2011


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/28/2011 05:10 PM, Chris McDonough wrote:
>> Why not modify sys.prefix?
>> - --------------------------
>>
>> As discussed above under `Backwards Compatibility`_, this PEP proposes
>> to add ``sys.site_prefix`` as "the prefix relative to which
>> site-package directories are found". This maintains compatibility with
>> the documented meaning of ``sys.prefix`` (as the location relative to
>> which the standard library can be found), but means that code assuming
>> that site-packages directories are found relative to ``sys.prefix``
>> will not respect the virtual environment correctly.
>>
>> Since it is unable to modify ``distutils``/``sysconfig``,
>> `virtualenv`_ is forced to instead re-point ``sys.prefix`` at the
>> virtual environment.
>>
>> An argument could be made that this PEP should follow virtualenv's
>> lead here (and introduce something like ``sys.base_prefix`` to point
>> to the standard library and header files), since virtualenv already
>> does this and it doesn't appear to have caused major problems with
>> existing code.
>>
>> Another argument in favor of this is that it would be preferable to
>> err on the side of greater, rather than lesser, isolation. Changing
>> ``sys.prefix`` to point to the virtual environment and introducing a
>> new ``sys.base_prefix`` attribute would err on the side of greater
>> isolation in the face of existing code's use of ``sys.prefix``.
> 
> It would seem to make sense to me to err on the side of greater
> isolation, introducing sys.base_prefix to indicate the base prefix (as
> opposed to sys.site_prefix indicating the venv prefix).  Bugs introduced
> via a semi-isolated virtual environment are very difficult to
> troubleshoot.  It would also make changes to existing code unnecessary.
> I have encountered no issues with virtualenv doing this so far.

I'm convinced that this is the better tradeoff. I'll begin working on a
branch of the reference implementation that does things this way. Thanks
for the feedback.

Carl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6uq2IACgkQ8W4rlRKtE2chHQCgik136LkoQ/JE6b3r4astWcog
kYYAoN7ESaPlZOaYeok5t0i9hMkb2L4g
=/Rn1
-----END PGP SIGNATURE-----


More information about the Python-Dev mailing list