On May 06, 2011, at 04:51 PM, Carl Meyer wrote: >On 05/06/2011 04:43 PM, Carl Meyer wrote: >> 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? > >Eh, never mind - guess it uses the actual directory when you provide a >script file to run, instead of running interactively. I never knew that.
Look down about line 762 (depending on version), and you'll see the Popen() call. It's basically calling $python /path/to/virtualenv.py where $python is the argument to -p. >> 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. > >Alternatively, could we actually follow the paths ourselves and ensure >the path that's being removed is the location of virtualenv.py? I'd just >rather not have the Debian-specific version of the fix in virtualenv. > >Or, if sys.path[0] being the script's directory is an absolute >guarantee, we could just skip the paranoia entirely? I think so. I'm fairly convinced sys.path[0] just isn't necessary to resolve any of the imports that virtualenv will need, at least in the common case. There may of course be some alternative usages I'm not aware of. But I think it's safe to say that sys.path[0] will always be the directory path containing virtualenv.py. Cheers, -Barry
signature.asc
Description: PGP signature
_______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
