The question of how long Python 2 will be available in Linux distributions

January 17, 2020

In theory Python 2 is now dead (sort of). In practice we have a significant number of Python 2 scripts and programs (including a Django web app, probably like many other places. Converting these to Python 3 is a make-work project we want to avoid, especially since it risks breaking important things that are working fine. One big and obvious issue for keeping on using Python 2 is that we use Linux (primarily Ubuntu) and normally use the system version of Python 2 in /usr/bin (although we're starting to shift how we invoke it). This obviously only works as long as there is a packaged version installed in /usr/bin, which raises the question of how long this will be available in Linux distributions.

Linux distributions like Debian, Ubuntu, and Fedora want to move away from officially supporting Python 2 because there is no upstream support (RHEL 8 will be supporting their version through 2024 or so). Of these, Debian and by extension Ubuntu have an idea of less-core packages that are built and maintained by interested parties, and I suspect that there will be people interested in packaging Python 2 even past when it stops being a fully supported package. Failing that being accepted, Ubuntu has the idea of PPAs, which people can use to distribute easily usable packages for Ubuntu (we get Certbot through a PPA, for example). Fedora doesn't quite have the packaging split that Debian does, but it has a PPA-like thing in COPR (also). I suspect that there is sufficient interest in Python 2 that people will provide PPAs and COPR repos for it.

(At the extreme end of things, we can and will build our own package of Python 2 if necessary by just re-building the last available version from a previous distribution release. We wouldn't get the ecology of additional Python 2 .debs or RPMs, but we don't need those.)

As far as I can tell, the current state of Python 2 in Fedora 32 is that Python 2.7 has become a legacy package as part of Fedora's plans to retire Python 2. The current Fedora plans have no mention of removing the 2.7 legacy Python package, but given how Fedora moves I wouldn't be surprised to see calls for that to happen in a few years (which would be inconvenient for me; a few years is quite fast here). Alternately, it might linger quietly for half a decade or more if it turns out to require no real work on anyone's part.

I expect Debian and Ubuntu to move more slowly than this but in the same direction. Ubuntu 20.04 may not be able to drop all packages that depend on Python 2.7, but by Ubuntu 22.04 I expect that work to be done and so Python 2 itself could be and probably will be demoted to a similar legacy status. Since 2022 is only two years away and Debian is not the fastest moving organization when it comes to controversial things like removing Python 2 entirely, I suspect that discussion of removing Python 2 itself will start no earlier than for Ubuntu 24.04. However I can't find a Debian or Ubuntu web page that talks about their future plans for Python 2 itself in any detail, so we may get surprised.

PS: In our environment, the issue with Python 2 going away (or /usr/bin/python changing which Python version it points to) isn't just our own system maintenance programs, but whatever Python programs our users may have written and be running. We likely have no real way to chase those down and notify the affected users, so any such shift would be very disruptive, especially because we run multiple versions of Ubuntu at once. With different Ubuntu versions on different machines, what /usr/bin/python gets you could vary from one machine to another. At that point we might be better off removing the name entirely; at least things with '#!/usr/bin/python' would fail immediately and clearly.


Comments on this page:

Incredibly silly idea on the notification front: move /usr/bin/python aside, replacing it with a tiny script that attempts to determine the invoking user's email address (eg $USER@utoronto.ca or whatnot) and sends them the desired notice before exec'ing the real Python binary.

There are a host of problems here (not least being how to do this consistently and globally, the fact that it'll spam users running anything noninteractively unless you use some form of caching, and that any service-oriented "user" accounts will not be notifying anybody real) but that's why the idea is silly :D

Unrelated: TIL about COPR. What a silly name.

By Todd at 2020-01-18 22:10:12:

At some point you gotta just consider giving in and converting your code to Python 3 or abandoning it, right? I mean, for pete's sake, we're sysadmins not magicians. We can only work with what we have, and two years from now Python 2 is not something we'll have.

By Stephen Kitt at 2020-01-20 09:30:07:

The Debian discussion on Python 2 is done and dusted, see https://wiki.debian.org/Python/2Removal for details. Debian 11 (2021, presumably) won't have Python 2, and the removal is well under way in Debian unstable and testing.

Written on 17 January 2020.
« How Go's net.DialContext() stops things when the context is cancelled
CUPS's page log, its use of SNMP, and (probably) why CUPS PPDs turn that off »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Jan 17 01:29:12 2020
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.