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

[Carl Meyer]

On 03/17/2011 08:35 PM, P.J. Eby wrote:
>> * I eliminated any form of generically-named config file, as I think the
>> extra possible names (and thus possible sources of confusion) is not
>> really worth the benefit. The only use case I can think of is if you
>> have multiple python binaries or symlinks next to each other and want
>> them all to use the same virtual config - and I can't really think why
>> you'd want multiple binaries in that case.
> 
> The main reason I'd use differently-named binaries would be if I were
> shipping multiple runnable applications that I wanted to look to users
> like true .exe's.  I don't see a reason why I wouldn't use separate
> .virtual.conf files, though, especially if their contents are minimal.

I've actually already backpedaled on this one as I considered it
overnight. For the virtualenv-style use case, you could easily end up
with e.g. "python" and "python-3.3" in your bin/ dir, and want them both
to reliably run in the virtualenv. So I think a fallback to
"python.virtual.conf" as a catchall is necessary after all.

> (Awesomeness bonus: if the executable put *itself* on sys.path, and ran
> __main__, you could simply tack a zipfile on the end of the .exe and
> have a ready-to-run application.)

Brandon Craig Rhodes was talking up that same idea (or something quite
similar) at PyCon. Scope creep for this PEP, I think, but interesting.

Carl