On May 04, 2011, at 11:15 AM, Carl Meyer wrote: >Virtualenv itself supports Python 2.4 - 3.2 from a single codebase, >beginning with the 1.6 release a few weeks ago, thanks to Vinay Sajip. >Try it out!
So I have some more information on this. Debian Wheezy has 1.6 now, but -p
python3 still did not work. Here is the bug report:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=625784
The problem occurs when virtualenv.py re-invokes itself. As you know, Python
puts the script's directory in sys.path[0]. On Debian virtualenv.py is a
symlink to /usr/share/pyshared/virtualenv.py so it's /usr/share/pyshared that
gets put on sys.path[0] on the second invocation. That directory will contain
Python 2's version of pkg_resources.py which naturally causes the traceback.
OT1H, this bug is due Debian policy of symlinking its modules so that they can
be shared, which doesn't play nicely with virtualenv's re-invocation. OTOH,
sys.path[0] isn't helpful in any case, and I can imagine some situations where
that could cause problems even on non-Debian systems.
I've worked up a patch, which you can find in the above tracker, that just
deletes sys.path[0] when VIRTUALENV_INTERPRETER_RUNNING is 'true' and when
sys.path[0] == '/usr/share/pyshared' (the latter is just paranoia ;). I've
verified this fixes the problem on Debian and doesn't seem to cause any bad
side-effects. I wonder if a similar patch shouldn't be applied upstream
though, to be sure that the re-invocation is insulated from the surrounding
environment?
Another suggestion given was to put virtualenv.py in a private directory,
i.e. not in Debian's equivalent of site-packages. I don't know whether there
are other packages that try to import virtualenv.py though, so to be safe, I
just went with the sys.path hacking.
Any thoughts?
Cheers,
-Barry
signature.asc
Description: PGP signature
_______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
