I use Arch so it's kind of a pain point when mucking around in servers (not a big deal, obviously, just something I have to keep in mind) and now that Python2 is no longer maintained, I've been doing a bit of research about whether there's any broad movement to deprecate the use of /bin/python
to point to /bin/python2
.
I've found this decent answer on askubuntu.com but it's rather out of date and so are the links.
The Ubuntu Python page says nothing about this re-aliasing.
Debian's Wiki says
NOTE: Debian testing (bullseye) has removed the "python" package and the '/usr/bin/python' symlink due to the deprecation of Python 2. No packaged scripts should depend on the existence of '/usr/bin/python': if they do, that is a bug that should be reported to Debian. You can use the 'python-is-python3' or 'python-is-python2' packages to restore an appropriate '/usr/bin/python' symlink for third-party or legacy scripts.
I'm not running Debian currently so I can't check, has Debian transitioned but Ubuntu hasn't? (As of 20.04 python -V
still says 2.7). I will admit I'm a bit fuzzy on the difference between /usr/bin
and /bin
and have found this decent explanation that I will shortly be reading.
The (considerably out of date) Ubuntu Python/3 page says that there is an ongoing project to make make python3 the default, but that /bin/python
will not change to /bin/python3
until there is a PEP that updates PEP 394. (I believe that might answer my question about Debian.)
The most recent update on the subject I can find is from an LWN article from 2/2019 titled Revisiting PEP 394
The eventual intent, at least according to a comment by Guido van Rossum on an earlier PR, is that python won't actually point anywhere because it won't exist; users will need to explicitly choose either python2 or python3. That is part of what Viktorin's PR is aiming for as well. He wants to make two changes to the PEP: allow installing a "python" (or, an "unversioned Python", as he calls it) to be optional for a distribution and to recommend that scripts supporting both Python 2 and Python 3 use python3 in their shebang lines. That last is a bit counterintuitive, since it means that those scripts will really only run under Python 3, regardless of their ability to run under either version. It is, Viktorin said, "the least bad option".
...
As he did at the language summit, Matthias Klose represented the Debian and Ubuntu Python packagers in the thread. He described the plans for unversioned Python; for Debian, python is never planned to point to Python 3, while Ubuntu has not made a final decision, but it currently does not install an unversioned Python. Debian will continue to have python point to Python 2 until it no longer ships Python 2, then remove it entirely. Klose is trying to ensure that, for upcoming distribution releases starting in 2020 or 2021, Python scripts in both Debian and Ubuntu packages use explicit shebang lines.
This says that Rossum is aiming to suggest deprecating /bin/python
altogether, and the plan for Debian is to wait until Debian drops Python2 altogether (what's the status on that?) and then just deprecate /bin/python
(or am I misunderstanding, because it also says Debian never plans to point python to python3). The suggestion that Ubuntu doesn't ship an unversioned Python doesn't make sense to me (I can definitely type python -V
and have it print 2.7 without doing anything special.
I'm hoping there's some community members with a bit more insight than this 2+ year old article, though I grant it seems this is a very slow moving issue. It just seems crazy to me that in 2021, Python2 being EOLed for over a year now, we're still treating it as the default on most systems. Most new users are probably surprised that typing python
on most systems would mean they were using deprecated software.
I do understand that this is a very difficult change, considering the insane number of legacy scripts that must be in operation on servers (obviously) not running Arch Linux. It's a simple fix to change #!/bin/python
to #!/bin/python2
but judging from how most companies treat legacy software I imagine it's a bit more onerous than popping a script open in an editor and adding a 3.