[Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream

[Glenn Linderman]

On 3/8/2011 10:27 PM, Mark Hammond wrote:
> On 9/03/2011 5:05 PM, Glenn Linderman wrote:
>>
>> Standard installation paths are accepted by about 99% of the users, so
>> embedding standard installation paths can work well for that batch of
>> users. Of course, Windows changes the standard path periodically, so
>> that it different from versions prior to and including WinXP versus
>> versions after WinXP. And they had no standard before WinNT (or if they
>> did, few followed it). Your comment does point out a possible need for
>> multiple standard installation paths just for different versions of
>> Windows, though :(
>
> The python installer ignores "Program Files" - as much as anything I'm 
> concerned about the drive letter - IIUC, Python will default to 
> installing on the system drive, which may not be C:

The system drive usually is C:, there is a fair bit of software that 
won't work when it is not C:, and in any particular corporate 
environment it is usually standardized by the IT folks.  And you are 
referring specifically to the CPython installer as the IronPython (for 
example) does install in Program Files.

>
> ...
>
>> Your premise that using a standard installation path in #@ restricts the
>> script to be targeted to one machine is fallacious, so the conclusions
>> are also.
>
> Sorry - I should have said "some machines with Python installed by the 
> installer".  Contrast this to the option of looking up the registry 
> and you have "all machines with Python installed by the installer".  
> I'm not going to quibble about the percentages in the first category 
> as I have no data to guide me, but I'm reasonably confident about the 
> "all" in the second.
>
> ...
>
>> The #! line is clearly is NOT "the only clue Windows needs to make it
>> work automagically" or we wouldn't be having this discussion at all.
>
> Sorry - I should have been clear - I meant "the only clue a windows 
> specific Python launcher needs".

Sorrier yet :)  I think you really meant "the only clue a Windows 
specific CPython specific Python launcher needs.

>
> > And
>> it is not at all clear if a Windows machine contains Jython, IronPython,
>> and Cython which one should be launched by a launcher.
>
> I think it is reasonably clear: it would be the same version which 
> would be launched on most *nix systems.  Are there any systems where 
> "/usr/bin/python" would use Jython, for example?

I have no idea the answer to your question... I don't think you do 
either.  There may be some.  The sysadmin can change what 
/usr/bin/python points to.  I have seen plenty of Unix systems where 
/bin/sh is really bash, for example, so if the replacement is 
"compatible enough" the sysadmin may choose to make such a change.


>> You could, of
>> course, argue that python-dev is only concerned with CPython, and the
>> launcher can be specific to CPython, and that argument might carry the
>> day, but the CPython registry lookup necessary to make that happen
>> doesn't help the users of alternate implementations a bit, forcing each
>> of them to implement their own launcher as well...
>
> I'd have no problem with the Windows launcher supporting other 
> implementations - I expect something like "/usr/bin/jython" would be 
> reasonable.  How we locate the installed jython is indeed an 
> interesting problem, but I'd guess it is surmountable - especially if 
> we can get the buy-in of these alternate implementations for their 
> future releases.

Indeed.  But now you have a script that require jython on all machines 
that it runs on, rather than being flexible in being configurable to use 
the preferred implementations of a particular environment (perhaps 
CPython 2.6 on Unix boxes, and Jython 2.5 on Windows boxes, or vice versa).


>
>> #!/usr/bin/env python2.6
>> #@"C:\Program Files\Env.exe" ipy2.6.3.exe
>
> As above, the C: assumes Windows is installed on C: - that may be 
> common, but not universal.  Further, a 64bit machine would probably 
> want "\Program Files (x86)" (which is becoming more and more common)

Yes, same C: issue as above, see response above.  And if the launcher 
comes in a 64-bit version for 64-bit machines, then it would be 
installed as C:\Program Files\Env.exe on the 64-bit machines.  That 
should be straightforward to achieve.


>
>>
>> in .py files and
>>
>> #!/usr/bin/env python2.6
>> #@"C:\Program Files\Env.exe" ipy2.6.3w.exe
>>
>> in .pyw files.
>
> I'm slightly skeptical about that - .pyw files are surely rare on *nix 
> systems and as we've discussed, pyw files are generally not meant to 
> be cmd-line scripts.  IOW, I'm skeptical scripts exist which are meant 
> to work with '/usr/bin/env python2.6' on *nix and pythonw.exe on windows.

Indeed, .pyw files are even rare on my Windows box :)

A GUI sort of Python script would generally want to be .pyw on a Windows 
box.  There are a variety of cross-platform GUIs such as Qt and 
wxWindows, so those same scripts could be written to work on Unix boxes 
also.  Unix, happily, doesn't care about the name of the script as long 
as the #! line points the right place, and neither does CPython on Unix, 
at least for non-module scripts (which are the ones that have #! lines 
anyway).  So it is quite conceivable, even if you have never done it 
personally.


>
> ...
>
>> So no matter what is done, it won't solve world hunger. Probably that's
>> why Windows users have been left high and dry for years in this
>> regard... there is no "system" Python on it, out of the box, so the only
>> users are those that are smart enough to download and install and
>> configure things, and those who use a Python embedded into an
>> application, at the cost of a Python installation per application,
>> because there has been no "system" Python, and because Windows users are
>> not perceived to be capable of, or willing to bother with, downloading
>> and installing various requisite dependencies.
>>
>> The resulting vacuum has been filled by people with different points of
>> view, because there has been no technique implemented, none declared to
>> be "best", and anarchy and variant workarounds have abounded.
>
> I'm glad solving world hunger is out of scope for this :)  I 
> understand your position but my personal opinion is that simple 
> support for #! is more desirable.  I'd be happy to go with the 
> consensus though...

The solution should be as simple as possible, but no simpler. -- Albert

I agree that parsing #! for a version and looking that up in the CPython 
registry entries would help in the limited circumstances where only the 
CPython implementation is of interest, and the same versions are 
available with the same names on all the machines of interest to the script.

Of course, my web host has /usr/bin/python (CPython 2.4.2),  
/usr/bin/python2.4 (Cpython 2.4.2) and /usr/bin/python (Cpython 2.6 -- 
apparently 2.6.0).  So when I choose the first, I get whatever the 
sysadmin chooses for that (they are slow to make changes for 
compatibility reasons, which is good).  When I choose the second for my 
#! line I get 2.4.2 there.  Now if I have  all of 2.4, 2.4.1, 2.4.3, and 
2.4.4 versions installed on my Windows box, which one should be run in 
the case of /usr/bin/python2.4?  The registry doesn't seem to tell which 
was installed first, second, or last.  Should it pick the newest, or the 
exact match of 2.4?  It can hardly intuit which version is most 
compatible with the other machines I run it on.  Whatever is picked 
would seem to be some heuristic.  And what if there is only 2.5 on the 
Windows boxes?  Or what if there is no CPython on the Windows box, but 
only Jython or IronPython, etc. the heuristics would have to understand 
all those mappings between versions... or simply not work at all, with 
no fallback technique to help it work.

With the #@ idea, application installers could ask which version of 
Python the application should be configured to use, from among the 
installed versions that the application has been tested with, and update 
the #@ lines, and that would stay constant for the life the application 
(and if the application has an installer that is that smart, it also 
wouldn't need a #! line, likely, when installed for Windows).  If there 
is no installer, then the user (or his sysadmin) must be smart enough to 
know how to use a text editor, and configure the version he wants by 
putting its path in the #@ line... and if the user (or his sysadmin) 
wants to use it cross-platform, then they put in the appropriate #! line 
for their Unix machines too.

Some configuration for the launcher would be required to handle the case 
where there is no #! line, or else in those cases, the launcher could 
report "no #@ line" like Unix's shell reports "syntax error" for python 
scripts handed to /bin/sh because the #! line was omitted.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110308/7f4e9bdd/attachment-0001.html>