[Distutils] pythonv: let's also make sure the standard Python install includes an "isolated" python

[Carl Meyer]

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