On Sat, Oct 29, 2011 at 4:37 AM, Carl Meyer email@example.com 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``.
I'm actually finding I quite like the virtualenv scheme of having "sys.prefix" refer to the virtual environment and "sys.real_prefix" refer to the interpeter's default environment. If pyvenv used the same naming scheme, then a lot of code designed to work with virtualenv would probably "just work" with pyvenv as well.