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 _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
