Hi Barry, On 05/06/2011 03:49 PM, Barry Warsaw wrote: > 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?
I don't quite understand this. On my Ubuntu system, with either Ubuntu's Python 2.6 or my compiled 3.2, sys.path[0] appears to always be the empty string, never the actual full path of the script's directory. How is it ever == '/usr/share/pyshared' for you? I was going to say that for a slightly less Debian-specific form of paranoia, could we only delete sys.path[0] if its in fact the empty string? But there seems to be something I'm still missing. > 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. Yes, there is code out there that imports virtualenv and uses it programmatically, and this is supported, so breaking it would be bad. Modulo my confusion about how your patch actually works, it seems like a reasonable approach to me, and I'd consider applying a non-Debian-specific version of the patch to virtualenv. Carl _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
