Re: [Distutils] pythonv: let's also make sure the standard Python install includes an "isolated" python
At 05:13 PM 3/17/2011 -0400, Jim Fulton wrote:
I suggest the following:
Look for argv[0]+'.pythonv' and then for '../pythonv.cfg'.
So if I've linked the Python executable to ./bin/clean, look for ./bin/clean.pythonv and ./pythonv.cfg.
And on Windows, presumably remove the .exe part? or are you saying 'python.exe.pythonv'?
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
At 07:53 PM 3/17/2011 -0400, Carl Meyer wrote:
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.
This combination should work well on Windows, where the default explorer settings will show e.g. 'python.virtual' next to 'python' in the directory. (Windows strips suffixes from display by default, and moves them to a "type" column.)
* 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. (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.)
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
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 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? I don't use OS X or have access to it, so happy to defer to those who know better, but when I've worked on others' OS X machines I think the binary has usually been just "python". I figured OS X was in the same boat as Linux, that if you've named your symlink python.foo you probably did it intentionally to distinguish it from another binary/symlink, and that shouldn't be stripped. Carl
On Fri, Mar 18, 2011 at 10:37 AM, Carl Meyer <carl@oddbird.net> 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:09 AM, Jim Fulton <jim@zope.com> 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; I don't recall it getting installed that way, though. On a case-senseless filesystem, distinguishing the "python" executable from the "Python" directory in the sources requires that unfortunate extension. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> "A storm broke loose in my mind." --Albert Einstein
On Fri, Mar 18, 2011 at 11:18 AM, Fred Drake <fdrake@acm.org> wrote:
On Fri, Mar 18, 2011 at 11:09 AM, Jim Fulton <jim@zope.com> 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 <fdrake@acm.org> 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 Fri, Mar 18, 2011 at 9:50 PM, Greg Ewing <greg.ewing@canterbury.ac.nz> 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. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> "A storm broke loose in my mind." --Albert Einstein
Fred Drake wrote:
On Fri, Mar 18, 2011 at 9:50 PM, Greg Ewing <greg.ewing@canterbury.ac.nz> 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...
Jim Fulton wrote:
None. Barry's been using Ubuntu too long and has forgotten that Mac OS X is Unix. :)
Or possibly he's thinking of the .app extension that application bundles have on MacOSX. But that's *not* the executable that gets run -- the actual executable is buried inside the Contents/MacOS directory of the bundle and usually has no extension. -- Greg
On Mar 18, 2011, at 10:37 AM, Carl Meyer wrote:
Hmm, really? What extension does the executable typically have on OS X that ought to be stripped?
As others have pointed out, the OS X build leaves a python.exe in the development tree, but installs without the .exe. I think it's useful to be able to create virtual environments with a build-tree version of Python. (I'd love to be able to verify this, but my OS X builds are failing atm.) -Barry
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
On Thu, Mar 17, 2011 at 6:08 PM, P.J. Eby <pje@telecommunity.com> wrote:
At 05:13 PM 3/17/2011 -0400, Jim Fulton wrote:
I suggest the following:
Look for argv[0]+'.pythonv' and then for '../pythonv.cfg'.
So if I've linked the Python executable to ./bin/clean, look for ./bin/clean.pythonv and ./pythonv.cfg.
And on Windows, presumably remove the .exe part? or are you saying 'python.exe.pythonv'?
I wasn't thinking that hard. Yes, remove the .exe part. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton
participants (8)
-
Barry Warsaw -
Carl Meyer -
Fred Drake -
Greg Ewing -
Jim Fulton -
Mark Sienkiewicz -
P.J. Eby -
Ronald Oussoren