[Python-ideas] Draft PEP for virtualenv in the stdlib

[Carl Meyer]

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

Thanks Konstantin, great questions.

On 10/26/2011 07:36 AM, Konstantin Zemlyak wrote:
> 1) There is no mention whatsoever about user site-packages directories
> from PEP-370.
> 
> Should they be supported inside venvs? Or should they be considered part
> of system-wide python?

Currently virtualenv considers user-site-packages part of the global
environment; they are not used if you supply --no-site-packages, and are
available otherwise. I think this is the right approach: an isolated
venv should really be isolated, and it would be odd for venv to provide
a mode where user-site-packages is available but global-site-packages
are not, since PEP 370 itself has no such provision.

I'll add an explicit section on this to the PEP, and verify that the
reference implementation handles it correctly.

I suppose a case might be made for a mode that makes
global-site-packages available but user-site-packages not? My
inclination is that this is not necessary, but I will add it as an open
question in the PEP, pending further feedback.

> 2) virtualenv keeps using platform-specific layout inside venv. So on
> POSIX for example this allows to install different python versions and
> implementations (like cpython and pypy, for example) into the very same
> venv. OTOH on Windows and in Jython there is only <prefix>\Lib per venv
> which makes this sharing impossible.
> 
> Should venvs support such use case? If so, how shebangs should be
> handled? What layout to endorse?

I don't think venv should go out of its way to support the case of
multiple interpreters in a single venv to any greater degree than Python
supports multiple interpreters under a single system prefix. In other
words, I'm perfectly happy to let this behavior vary by platform, in the
same way it already varies at the system level, and not consider it a
supported use case.

Virtualenv makes no effort to support sharing an env among multiple
interpreters, and this has not been a requested feature.

Note that "sharing a venv" in the POSIX layout has very few advantages
over having a separate venv per interpreter/version, and some
significant disadvantages. You don't gain any disk space savings, and
you lose a great deal of explicitness, particularly in that installed
scripts will generally have a shebang line pointing to whichever
interpreter you happened to install them with, possibly overwriting the
same script previously installed by a different interpreter. If people
on POSIX systems want to do this, that's fine, but I don't think it
should be documented or encouraged.

> 3) This might be not relevant to this PEP but I wonder how would
> implementing this proposal affect other implementations like Jython,
> PyPy and IronPython. Will they be able to implement this functionality
> the same way?

Good question. Virtualenv already supports PyPy and I'm fairly confident
PyPy will not have trouble with this PEP. I don't know about IronPython
or Jython - as long as they follow the same algorithm for finding
sys.prefix based on sys.executable, it should work the same. I will add
an "open question" on this topic to the PEP, and hopefully we can get
some feedback from the right people when we take this to python-dev.

Thanks for the review!

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

iEYEARECAAYFAk6oR+QACgkQ8W4rlRKtE2ddegCgxfLsZNtNFsFNxA/bFkBdgBVQ
DyYAoJ9Grvu7d4g+EOBKhyHE0l8qwq0x
=dfqF
-----END PGP SIGNATURE-----