In a message of Fri, 06 May 2011 16:49:15 EDT, Barry Warsaw writes:

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=3D625784

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

Holger will have an opinion on this. And I think tox http://codespeak.net/tox/index.html tries to import virtualenv.py . Laura