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

Carl Meyer carl at oddbird.net
Wed Oct 26 03:21:53 CEST 2011


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

Hi Barry,

Thanks for the review and feedback.

On 10/25/2011 02:34 PM, Barry Warsaw wrote:
>> My original thinking here was that sys.site_prefix is an attribute that
>> should always exist, and always point to "where stuff should be
>> installed to site-packages", whether or not you are in a venv (if you
>> are not, it would have the same value as sys.prefix). It's a little odd
>> to use an attribute named "sys.venv_prefix" in that way, even if your
>> code doesn't know or care whether its actually in a venv (and in general
>> we should be encouraging code that doesn't know or care). (The attribute
>> doesn't currently always-exist in the reference implementation, but I'd
>> like to change that).
> 
> That makes sense to me.  It would be nice to have the location of your
> site-prefix always available for calculations regardless of your
> "virtualness".  Note that in all likelihood, Debian will have to modify that
> so that it points to dist-packages instead of site-packages.  Will there be an
> easy hook/config file or some such that we could use to make that change?

As it currently stands, this is really just the/a _prefix_ under which
site-packages is found (parallel to how sys.prefix is currently used).
Which means "site-packages" vs "dist-packages" is still determined in
site.py, which tacks platform-specific paths onto the end of the prefix
in order to find the actual site-packages directory. So in the Debian
case, you'd still have to modify your distributed site.py (and take a
bit of care, assisted by the tests, that you don't break venv.py in the
process); I don't think this PEP really changes that much.

(Though the fact that not breaking virtual environments when you make
distro-specific modifications to site.py becomes your responsibility as
the distro Python maintainer rather than mine as virtualenv maintainer
is, in my humble opinion, one of the greatest advantages of this PEP <wink>)

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

iEYEARECAAYFAk6nYLEACgkQ8W4rlRKtE2ftGgCfQr0m9WM5BtDxFZfqepbxqqxn
+kIAniTBdvxWh/Bsg4rOEdGMYnIIpKmD
=CMax
-----END PGP SIGNATURE-----



More information about the Python-ideas mailing list