FWIW, I've pushed a reworking of the config-file-finding, with the following shed-paint color choices: * File is named <executable-name>.virtual.conf (I kept the .virtual, despite it being longer and not strictly necessary, because I think it more clearly expresses the function of the file. The existence or absence of this file changes Python's behavior significantly, so I think its name should be quite explicit.) * <executable-name> has the extension stripped on Windows, but not otherwise. * Config file can be located adjacent to the binary or one level up. The default sys.prefix is always the directory in which the configuration file is found, but can be overridden with a new "prefix" setting in the config file (which can be a path relative to the config file's location). * 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. Substantive comments on these choices is fine, especially in the form of presenting real use-cases I'm not currently allowing for. Testing that reveals a flaw in the basic operation of this style of virtual environment is much more useful. The bikeshed colors are easy to change, but I want to be really sure this thing actually does what it's supposed to reliably before I go presenting a PEP for it. Thanks! Carl

Sounds good to me. On Mar 17, 2011, at 07:53 PM, Carl Meyer wrote:

* <executable-name> has the extension stripped on Windows, but not otherwise.

It should probably also have the extension stripped on OS X too. -Barry

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

On Fri, Mar 18, 2011 at 10:37 AM, Carl Meyer wrote:

On 03/17/2011 09:33 PM, Barry Warsaw wrote:

...

On Mar 17, 2011, at 07:53 PM, Carl Meyer wrote:

...

* <executable-name> has the extension stripped on Windows, but not otherwise.

It should probably also have the extension stripped on OS X too.

Hmm, really? What extension does the executable typically have on OS X that ought to be stripped?

None. Barry's been using Ubuntu too long and has forgotten that Mac OS X is Unix. :) Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton

On Fri, Mar 18, 2011 at 11:18 AM, Fred Drake wrote:

On Fri, Mar 18, 2011 at 11:09 AM, Jim Fulton wrote:

...

None. Barry's been using Ubuntu too long and has forgotten that Mac OS X is Unix. :)

There's also the fact that Python on Mac OS X builds with a .exe extension;

Oh wow. In the build directory, it does have a ".exe" extension.

I don't recall it getting installed that way, though.

Right. It's installed without the extension.

 On a case-senseless filesystem, distinguishing the "python" executable from the "Python" directory in the sources requires that unfortunate extension.

So sad. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton

Jim Fulton wrote:

On Fri, Mar 18, 2011 at 11:18 AM, Fred Drake wrote:

...

On a case-senseless filesystem, distinguishing the "python" executable from the "Python" directory in the sources requires that unfortunate extension.

So sad.

We don't have to make it look so Windows-like, though. We could use something more cheerful such as 'python.nothisisnotthedirectory'. :-) -- Greg

On 17 Mar, 2011, at 21:33, Barry Warsaw wrote:

Sounds good to me.

On Mar 17, 2011, at 07:53 PM, Carl Meyer wrote:

...

* <executable-name> has the extension stripped on Windows, but not otherwise.

It should probably also have the extension stripped on OS X too.

There is no extension on OSX. There is one in the build tree, but that's because the default filesystem on OSX is case insensive and hence the name 'python' is already taken during a build. Ronald

Fred Drake wrote:

On Fri, Mar 18, 2011 at 9:50 PM, Greg Ewing wrote:

...

We don't have to make it look so Windows-like, though. We could use something more cheerful such as 'python.nothisisnotthedirectory'.

Yes, but... the sad part is that a turd has to be added, or the name changed in even less satisfactory ways. Case-senselessness is still senseless.

/me mourns the loss of case-sense in "pop" operating systems.

Actually, "loss" is not quite what happened here. Unix-derived systems (Unix, Linux, *BSD) are somewhat unusual in having case-sensitive file systems. Of the alphabet soup of operating systems that I've used, I can remember case sensitive files systems in the Unix-like systems, Plan 9, and Apple II DOS -- but the Apple II doesn't have lower case letters on the keyboard/display, so I'm not sure it counts. I used to think that case-sensitive identifiers are a good idea, but I now think that it is just too error-prone to use identifiers that differ only in case. Also, it's not portable... :) b.t.w. The extension is ".cfg" because RT-11 stored file names in a character set called "Radix 50" that could pack 3 characters into a 16 bit word. CP/M pretty obviously copied RT-11, MS-DOS copied CP/M, and MS Windows was originally a GUI framework for MS-DOS. Meanwhile, Unix initially ran on other DEC systems, so a lot of early Unix users had contact with RT-11 or its descendants, and re-used some of the same conventions. So, "We use .cfg because we have calling it that since 1970..." Interesting, but perhaps not a particularly compelling reason. :)

sniff< - what's that smell? Oh yeah -- old farts...