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

[Kerrick Staley]

The point is that there never has to be an agreement about the python
command, as long as all distros support python2/python3 and all scripts use
it (I think that the distinction should continue to be made if/when python2
becomes uncommon, otherwise we'll hit the same issue with python4). We don't
have to force anyone to change the python command itself.

That being said, I feel that the python command should only be invoked from
an interactive terminal, and in fact it would be good if distros would use
the python2/python3 convention in their own packages, so that the sysadmin
can point python to wherever he wants, and when he types python into a
terminal get the version he wants. As an added plus, should a distro
supporting this feature decide to make the Python 2 -> Python 3 switch, it
would be an effortless process. Again, however, force this requirement
shouldn't be forced on distros.

As an aside, this whole thing started when I tried installing
ROS<http://www.ros.org/wiki/>,
only to find that it made assumptions about /usr/bin/python, which points to
python3 on my Arch Linux system. I went in search of documentation for the
python2/python3 convention so that I could make the ROS developers aware of
it and help them to follow it, only to find out that no such convention
actually exists. Since ROS uses a rather complicated python-based installer
that makes assumptions about /usr/bin/python not only in the shebangs of
many files but also in other places (apparently in connection with the
subprocess module), it has proven thus far unworkable unless I change
/usr/bin/python back to Python 2, a move that could potentially break many
other aspects of my system. I'm sure there are many other users out there
that are frustrated by similar issues; supporting a python2/python3
convention on all distros as well as in scripts would solve these issues
without creating further problems and without the need for a slow consensus
to be reached on what /usr/bin/python should be.

Here is a draft PEP (forgive me if it's incorrectly formatted; I've never
done this before). I think it's a little long winded given how simple the
idea it proposes is, but I thought it would be better to be more specific
than necessary rather than less.
.
PEP: ???
Title: The python Command on Unix-Like Systems
Version: ???
Last-Modified: ???
Author: Kerrick Staley <mail at kerrickstaley.com>
Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: 02-Mar-2011
Post-History: ???

Abstract
==========
This PEP provides a convention to ensure that Python scripts can continue to
be portable across *nix systems, regardless of the default version of the
Python interpreter (i.e. the version invoked by the "python" command).

Recommendation
================

* ``*nix`` software distributions should install the command "python2" into
the default path whenever a version of the Python 2 interpreter is
installed, and the same for "python3" and the Python 3 interpreter. When
invoked, "python2" should run some version of the Python 2 interpreter, and
"python3" should run some version of the Python 3 interpreter.
* All new code that needs to invoke the Python interpreter should specify
either "python2" or "python3", according to the version it requires, but not
"python". This distinction should be made in shebangs, when invoking from a
shell script, when invoking via the system() call, or when invoking in any
other context.

Rationale
===========

This is needed because some distributions alias the "python" command to
Python 3, while others alias it to Python 2. Some distributions also do not
provide a "python2" command; hence, there is no way for Python 2 code (or
any code that invokes the Python 2 interpreter) to reliably run on all
systems without modification, because both the "python" and the "python2"
commands will fail on some systems. The recommendations in this PEP provide
a very simple mechanism to restore cross-platform support, with very little
additional work required on the part of distribution maintainers.

Notes
=======

* Distributions can alias the "python" command to whichever version of the
Python interpreter they choose.
* It would be wise for distributions to always follow the convention that
this PEP recommends, even in code that is not intended to operate on other
distributions. This will make it easier if the code ever needs to be ported
to another distribution or if the distribution decides to change the version
of the Python interpreter that the "python" command invokes. Distributions
can test whether they are fully following this convention by switching the
"python" interpreter and seeing if anything breaks.
* If the above point is adhered to, then the "python" command should always
be a link to the interpreter binary (or a link to a link) and not vice
versa. That way, if users decide to change where the "python" command
points, they can do so without inadvertently deleting the binary.
* The first recommendation can be ignored for systems on which the python
command itself has traditionally been left undefined and users have always
had the responsibility of linking the "python" command to the Python
interpreter.
* If the Python 2 interpreter becomes uncommon, scripts should nevertheless
continue to use the "python3" convention rather that just "python". This
will ease transition in the event that yet another major version of Python
is released.
* If these conventions are adhered to, it will be the case that the "python"
command is only executed in an interactive manner.

Backwards Compatibility
=========================
A potential problem can arise if a script adhering to the
"python2"/"python3" convention is executed on a system not supporting these
commands. This is mostly a non-issue, since the sysadmin can simply create
these symbolic links and avoid further problems.

Copyright
===========
This document has been placed in the public domain.

EOF

-Kerrick Staley

On Wed, Mar 2, 2011 at 9:13 AM, James Y Knight <foom at fuhm.net> wrote:

> On Mar 2, 2011, at 9:54 AM, Allan McRae wrote:
> > That way in ?? years when python-3.x is "the" python and python-2.x is
> obsolete, and it is decided that /usr/bin/python will be python-3.x (which I
> believe is the only logical outcome),
>
> But that's not the only logical outcome. A perfectly logical outcome is
> that /usr/bin/python disappears completely if python2.X isn't installed, and
> python3 is always called python3. That is the outcome I find sensible. And
> that is the crux of the disagreement in this thread.
>
>
> Those who think python3.X should stay /usr/bin/python3 forever do not see
> any reason to make everyone rewrite their existing python scripts to say
> "/usr/bin/python2" instead of "/usr/bin/python". So, there's no point in
> adding a /usr/bin/python2 now. Scripts that want python2 can remain using
> /usr/bin/python forever, and that will either be installed, or not
> installed, depending on whether that OS has a copy of python2.X.
>
> Those who think python3 should (eventually someday, or maybe immediately,
> depending) be named or have an alias of "/usr/bin/python" want to make
> everyone rewrite their scripts to say /usr/bin/python2 now. For that
> position, it's unfortunate that python source doesn't install itself with an
> alias of /usr/bin/python2, and some distros don't install that alias either.
> So they want to fix that.
>
> James
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/mail%40kerrickstaley.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110302/9c90de37/attachment.html>