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.