On 03/17/2011 01:23 PM, Jim Fulton wrote: > My understanding of how this will work was that I could created this > myself by creating some sort of configuration file, say clean.cfg and > then link a Python executable to the name "clean". Reading "pythonv, > take two" more carefully, I see that it is a lot more > virtualenv-oriented than I'd hoped. <shrug> > >> I'm also not entirely clear what this means, but I think perhaps "python >> -S" already covers it? > > I thought so too, but people keep telling me that's not enough. One > issue was that maybe site.py might be imported accidentally, for > example to get at one of the helper functions it contains. I don't > know if this is a significant danger. > > I'd like to have some defined way to express my need for isolation > that's more rubust that simply not importing site.py.
Actually, now that I come to think of it, pythonv (take two) does already cover your requirement. If you have a symlinked or copied python binary, and an empty pythonv.conf one directory up, and you simply _don't_ create any lib/python3.3/site-packages relative to pythonv.conf, what you'll end up with is identical to "python -S" but robust against import of site.py (it will already have been imported, but it won't have found any site-packages directories). If the possibility of someone accidentally creating lib/python3.3/site-packages is an issue, we could easily add a "no-site=True" option to pythonv.conf that would prevent it from even checking for the existence of that directory. And in either case, we could add a --no-site option to "python -m pythonv" that would create a virtualenv without the site-packages directory (and with no-site=True, if we decide that's worth having). Carl _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
