[Python-ideas] Migration of /usr/bin/python to python3

[Nick Coghlan]

On 12 March 2015 at 06:14, Donald Stufft <donald at stufft.io> wrote:
> What's worse. Breaking everything that uses an unversioned shebang because /usr/bin/python doesn't exist or breaking some things that doesn't work with Python 3 because /usr/bin/python is now 3?
>
> Generally discussions along this line talk about Python 2 not being installed by default at all (whereas Python 3 would be). So really it's two different broken by default.

Right, this most recently came up in the context of Fedora's plans to
transition to only having Python 3 in the base install
(https://fedoraproject.org/wiki/Changes/Python_3_as_Default). At the
moment the expected consequence is that there will come a Fedora
version (tentatively Fedora 23) where, out of the box,
"/usr/bin/python" and "/usr/bin/env python" will just stop working.

Packages that are part of the distro aren't a problem - those are all
being dealt with as the transition progresses, and any which
specifically need Python 2 will depend on it accordingly.

The problem arises with custom user packages and scripts, and third
party packages and scripts. For those, we either just let them break,
or we automatically try running them in Python 3 by change the package
that provides the "/usr/bin/python" symlink. This is actually going to
happen well in advance of Python 3.6, so my original suggestion of
deferring a decision until then (the other discussion Neal was
referring to when starting this thread) won't actually help (as Fedora
23 is due out later this year, while even a slip to Fedora 24 would
still put this change in early 2016).

In favour of moving the symlink to the Python 3 package when Python 3
is the only version a distro installs by default:

* Python 2/3 compatible scripts will "just work"
* Python 3 incompatible scripts will hopefully get a useful error that
points them in the right direction (such as
https://stackoverflow.com/questions/25445439/what-does-syntaxerror-missing-parentheses-in-call-to-print-mean-in-python)
* if the script author is only worried about PEP 394 compliant
environments, they can update their shebang line to "python2", or else
they can set it to "python2.7" if they aren't worried about older
Linux distros that only provide Python 2.6 or earlier.

If we went down this path, Fedora would likely consider enabling
deprecation warnings and Py3k warnings in Rawhide and the Alphas of
the previous release (where Python 2 was still the default) to help
gauge the likely impact.

The case against moving the symlink:

* while it's convenient, running arbitrary user code in the system
Python is also going to be a compatibility/maintainability issue for
both distro developers and our users
* for the Fedora/CentOS/RHEL ecosystem, Software Collections use
environment modules to switch the active Python:
https://www.softwarecollections.org/en/
* if the python symlink is taken away entirely, then it's an
opportunity to give users the choice of either installing the "system
Python 2 stack" (which will be effectively unchanged, just not
installed by default) *or* of installing the Python 2.7 Software
Collection, and getting used to the idea of leaving the system Python
alone
* the advantage of Software Collections is that they support parallel
installation by design, so user's can upgrade their distro without
upgrading the collections they're using, and vice-versa
* other utilities like pyenv and conda similarly support parallel
installs by design

Going down this path would basically mean saying that "python" at the
system level would no longer be defined at all once Python 2 goes EOL
in 2020. A "default" Python would only exist inside an activated
environment module, whether defined by scl, pyenv, conda, or another
tool.

Adopting the latter approach would mean saying "No change to PEP 394"
upstream, and thus passing the situation back to Fedora to decide how
to handle.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia