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