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.