Hi all,
During the huge thread about PEP 394, a suggestion was made that a
"launcher" for Python on Windows could be implemented which would allow
for some of the guidelines in that PEP to apply to the Windows version
of Python.
I've attached the first draft of a PEP for such a launcher and put the
first draft of the "reference implementation" (implemented in Python 3)
at http://starship.python.net/crew/mhammond/downloads/python_launcher.py
The reference implementation is fairly complete WRT the features
described in the PEP. However, I'm sure there will be comments on both
the PEP itself and the implementation, so I'm putting them up for
discussion now rather than spending more time polishing things which may
end up changing. I'll start work on a C implementation once there is
broad agreement on the functionality in the reference implementation.
All comments welcome, including, but not limited to:
* Is this really PEP material, or will turning the PEP into a regular
spec be suitable?
* If it is a PEP, is it "Standards Track" or "Informational"?
* Does the functionality described strike the right balance between
simplicity and usefulness?
* Does the strategy have general support from Martin, who as the person
making Python distributions would need to be involved in at least some
aspects of it (specifically, having the installer MSI install the
launcher and update the file associations to reference it).
Thanks,
Mark
PEP: ??
Title: Python launcher for Windows
Version: $Revision$
Last-Modified: $Date$
Author: Mark Hammond <mhamm...@skippinet.com.au>
Status: Draft
Type: Standards Track or Informational ?????
Content-Type: text/x-rst
Created: 15-Mar-2011
Abstract
This PEP describes a Python launcher for the Windows platform. A
Python launcher is a single executable which uses a number of
heuristics to locate a Python executable and launch it with a
specified command line.
Rationale
Unix-like operating systems (referred to simply as "Unix" in this
PEP) allow scripts to be executed as if they were executable images
by examining the script for a "shebang" line which specified the
actual executable to be used to run the script. This is described in
detail in the evecve(2) man page [1].
Additionally, these operating systems provide symbolic-links to
Python executables in well-known directories. For example, many
systems will have a link /usr/bin/python which references a
particular version of Python installed under the operating-system.
These symbolic links allow Python to be executed without regard for
where Python it actually installed on the machine (eg, without
requiring the path where Python is actually installed to be
referenced in the shebang line or in the PATH. PEP 394 'The "python"
command on Unix-Like Systems' [2] describes additional conventions
for more fine-grained specification of a particular Python version.
These 2 facilities combined allow for a portable and somewhat
predictable way of both starting Python interactively and for allowing
Python scripts to execute. This PEP describes an implementation of a
launcher which can offer the same benefits for Python on the Windows
platform.
An overview of the launcher.
This PEP outlines the general functionality and key guidelines of a
launcher for Windows. It is accompianied by reference implemention,
written in Python, which defines the detailed implementation. Over
time, changes to the implementation may be desired - if the changes
adhere to the guidelines in this PEP and have been made following
the standard Python development model, this PEP need not change.
In other words, this PEP makes no attempt to describe in detail every
feature offered by the launcher, but instead to offer guidelines the
launcher should adhere to.
The actual implementation of the launcher will be written in C and
will not link directly or indirectly with Python, but the Python
based reference implementation should always remain the canonical
description of the functionality. Any changes proposed to the
launcher functionality should first be made and agreed to in the
Python implementation, after which time the C implementation can be
changed to reflect the new reference. Any deviations between the
functionality of the reference implementation versus the C
implementation due should imply the C implementation is in error.
It is expected that 2 versions of the launcher will be needed - one
which is a console program and one which is a "windows" (ie, GUI)
program. These 2 launchers correspond to the 'python.exe' and
'pythonw.exe' executables which currently ship with Python. The
console launcher will be named 'py.exe' and the Windows one named
'pyw.exe'. The "windows" (ie, GUI) version of the launcher will attempt
to locate and launch pythonw.exe even if a virtual shebang line nominates
simply "python" - infact, the trailing 'w' notation will not be supported
in the virtual shebang line at all.
The launcher will be distributed with all future versions of Python
and if possible, should be installed somewhere likely to already be
on the system PATH (eg, the Windows System32) directory. If installed,
the "console" version of the launcher should be associated with .py files
and the "windows" version associated with .pyw files.
The launcher will not be tied to a specific version of Python - eg, a
launcher distributed with Python 3.3 should be capable of locating and
executing any Python 2.x and Python 3.x version. Future versions of the
launcher should remain backwards compatible with older versions, so later
versions of Python can install an updated version of the launcher without
impacting how the previously installed version of the launcher is used.
Guidelines for a Python launcher.
The launcher should be as simple as possible (but no simpler.)
The Python launcher described in this PEP will intentionally be
constrained to the use-cases described in the Rationalle section
above. It will not attempt to be a general purpose script launcher
or shebang processor and will, in general, limit itself to the
features offered by Unix.
The launcher should support for format of shebang lines as described
in [1], including all restrictions listed.
The launcher should support shebang lines commonly found on Unix.
For example, a shebang line of '!# /usr/bin/python' should work even
though there is unlikely to be an executable in the relative Windows
directory "\usr\bin". This means that many scripts can use a single
shebang line and be likely to work on both Unix and Windows without
modification.
The launcher should support fully-qualified paths to executables.
While this will make the script inherently non-portable, it is a
feature offered by Unix and would be useful for Windows users in
some cases.
The launcher should be capable of supporting implementations other
than CPython, such as jython and IronPython. In particular, if there
are common symbolic links used on Unix to specify such an
implementation (such as "/usr/bin/jpython", the launcher should
support such references on Windows. However, the launcher on Windows
need not create its own conventions for use on Windows - ie, if
"/usr/bin/jython" is not commonly found on Unix and therefore does
not commonly exist in shebang lines, the Windows launcher need not
support it. The ability to specify the fully-qualified path to the
executable could be used just as it would need to be done on Unix.
As the launcher takes the place of Unix symbolic links without using
links on Windows, the following concessions will be made:
* Environment varialbes will be used to override the semantics for
determining exactly what version of Python will be used. For
example, while a shebang line of "/usr/bin/python2" will
automatically locate a Python 2.x implementation, an environment
variable can override exactly which Python 2.x implementation will
be chosen. Similarly for "/usr/bin/python" etc.
* When used to launch an interactive Python interpreter, the launcher
will support the first command-line argument optionally be a
version specifier in the form "-n[.n]" (where n is a single
integer) to nominate a specific version be used. For example,
while "py.exe" may locate and launch the latest Python 2.x
implementation installed, a command-line such as "py.exe -3" could
specify the latest Python 3.x implementation be launched, while
"py.exe -2.6" could specify Python 2.6 be located and launched.
If a Python 2.x implementation is desired to be launched with the
-3 flag, the command-line would need to be similar to "py.exe -2
-3" (or the specific version of Python could obviously be
launched manually without use of this launcher.)
While the guidelines above are general, the launcher should make
concessions for any Windows specific issues which increase the
usefulness of the launcher on Windows. In other words, the
guidelines above will not override Windows specific functionality
which makes the launcher significantly more useful for Windows
users.
Shebang lines parsing
A shebang line will be parsed according to the rules in [1]. Once
parsed, the command will be examined to see if it is a "virtual
command". A virtual command starts with either of the 2 strings
'/usr/bin/python' or '/usr/bin/env python'.
Commands which are virtual are not treated as containing a file-system
path, but instead are treated as references to an installed Python.
Optionally, the virtual command may include a specific version, such
as '/usr/bin/python2' or '/usr/bin/python3.2'. If only a "major version"
qualifier is found, the launcher will enumerate the installed Python
versions and use the latest minor release found for the major version,
which is likely, although not guaranteed, to be the most recently
installed version in that family. If major and minor version qualifiers
are found, that specific version will be located and used.
Note that the "bitted-ness" of Python versions is yet to be considered.
While is seems reasonable that a 64bit OS will prefer a matching 64bit
version if available, there may also be the requirement to allow this
to be explicitly nominated on the shebang line (eg
'/usr/bin/python3.2-64'). It may be reasonable to defer this until
after a first implementation on the assumption of YAGNI and allow wider
feedback to guide future enhancements.
If a virtual command has no version specifier, the launcher will
attempt to locate a Python 2.x installation and use the latest
found. If none are found, it will attempt to use the latest Python
3.x implementation found.
The use of 'virtual' shebang lines will be encouraged as this should
allow for portable shebang lines to be specified which work on
multiple operating systems.
If the shebang line is not a virtual one as described above, it is
assumed to be a path to an executable - presumably a Python
executable, but this will not be checked. No version qualifiers are
parsed - if a specific version is required, then the path should
reflect that. Releative path specifications will be considered
relative to the directory of the launcher. Thus, a shebang line of
'#! python' will look for a python executalbe in the same directory
as the launcher.
Non-virtual shebang lines should be discouraged as they make the
script specific to a specific Windows installation. However, they
are supported for maximum flexibility.
References
[1] http://linux.die.net/man/2/execve
[2] http://www.python.org/dev/peps/pep-0394/
Copyright
This document has been placed in the public domain.
Local Variables:
mode: indented-text
indent-tabs-mode: nil
sentence-end-double-space: t
fill-column: 70
coding: utf-8
End:
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
