Fedora and Python 2

Benefits for LWN subscribers The primary benefit from subscribing to LWN is helping to keep us publishing, but, beyond that, subscribers get immediate access to all site content and access to a number of extra site features. Please sign up today!

It has been known for quite some time that Python 2 will reach its end of life in 2020—after being extended by five years from its original 2015 expiry. After that, there will be no support, bug fixes, or security patches for Python 2, at least from the Python Software Foundation and the core developers. Some distributions will need to continue to support the final Python 2 release, however, since their support windows extend past that date; the enterprise and long-term support distributions will likely be supporting it well into the 2020s and possibly beyond. But even shorter-support-cycle distributions need to consider their plan for a sweeping change of this sort—in less than two years.

There was talk of having the actual end of life (EOL) occur at a party at PyCon 2020, but a mid-March query to the python-dev mailing list helped nail down the date once and for all. Currently, the only supported branch in the 2.x family is Python 2.7, which is up to 2.7.14 and is scheduled to have a 2.7.15 release sometime in 2018. It seems likely there will be at least one more release before EOL, which Python benevolent dictator for life (BDFL) Guido van Rossum proclaimed will be January 1, 2020:

The way I see the situation for 2.7 is that EOL is January 1st, 2020, and there will be no updates, not even source-only security patches, after that date. Support (from the core devs, the PSF, and python.org) stops completely on that date. If you want support for 2.7 beyond that day you will have to pay a commercial vendor. Of course it's open source so people are also welcome to fork it. But the core devs have toiled long enough, and the 2020 EOL date (an extension from the originally [announced] 2015 EOL!) was announced with sufficient lead time and fanfare that I don't feel bad about stopping to support it at all.

Benjamin Peterson, who is the 2.7 release manager, agreed, though he cautioned that the final 2.7 release may not literally be made on new year's day 2020. Others took notice of the date, including Petr Viktorin and the other maintainers of the python2 package for Fedora. Viktorin posted a message to the Fedora devel mailing list on behalf of all of the nine python2 maintainers that noted the EOL date and their intent to "orphan" the python2 package:

Fedora still has more than 3000 packages depending on python2 – many more than we can support without upstream help. We (rightly) don't have the authority to say "please drop your unneeded python2 subpackages, or let us drop them for you" [0] . The next best thing we *can* say is: "if Fedora is to keep python2 alive, we won't be the ones doing it – at least not at the current magnitude".

The first Fedora release that would be affected by the EOL date is probably Fedora 30, which is likely to land in the first half of 2019—and be supported into 2020. But, Viktorin argued, it makes sense to get started now by removing python2 dependencies for packages that don't really need them:

Unlike most other orphanings, we have some thousands of dependent packages, so a lot of time and care is required. In case no one steps up, we'd like to start dropping Python 2 support from dependent packages *now*, starting with ported libraries on whose python2 version nothing in Fedora depends. (We keep a list of those at [1] .) Of course, we're ready to make various compromises with interested packagers, as long as there's an understanding that we won't just support python2 forever.

There was some confusion about what was being suggested but, in general, the reaction was positive. A rude complaint that the problem was essentially impossible to solve was met with strong disagreement. As Richard W.M. Jones pointed out: "it's hard to argue with a plan which has been pre-announced *2 years* in advance. If only all Fedora changes were given such a generous runway." But Randy Barlow wondered if the proposed incremental approach was right:

I'm +1 to the idea of dropping Python 2 support in general, but I'm not sure we should really do it gradually (which is what would effectively happen if some packagers start dropping now and others later, and others not at all). It seems to me like it'd be cleaner to have a release note on Fedora 30 that's just "Python 2 support dropped" and do it all at once.

That kind of cataclysmic approach might work for the Python code actually shipped by Fedora, but there is plenty of other code out there to consider. Python is, after all, a programming language, so there is an unknowable amount of Python 2 running on Fedora users' machines right now. A more cautious approach gives them time to notice and upgrade; as Gerald Henriksen put it:

By gradually (or sooner than Fedora 30) getting rid of all the libraries and other Python 2 stuff it at least gives the option for those people who get surprised to fix things before the Python interpreter itself goes EOL and doesn't get security fixes.

It should be possible to continue supporting Python 2.7 into 2020 and beyond by piggybacking on the work that the enterprise distributions will be doing. It is also possible, though perhaps not all that likely, that few or no security flaws will be found in the language after it drops out of its support window. RHEL 7 and CentOS 7 ship Python 2.7; both of those distributions will receive updates until 2024. That should help with keeping Python 2 alive, Kevin Kofler said; borrowing patches from RHEL/CentOS is something he has been doing for Qt and kdelibs for some time. As Viktorin pointed out, the Fedora Python SIG is already maintaining some EOL Python versions; it will do the same for Python 2.7:

As Python SIG we maintain old Python versions like 2.6 or 3.3 *today* – but just for developers who need to test backwards compatibility of their upstream libraries; we don't want to see them used as a base for Fedora packages. Why? To make sure Fedora packages work with modern Python, and to have only one time-sensitive place to concentrate on when a critical security fix comes. We want to put Python 2.7 in the same situation. Part of the reason to start dropping Python 2 packages now is to figure out which packages can do it now and which ones will need additional help or coordination in the next few years.

Beyond just backward compatibility, though, Viktorin and company have another reason they are willing to maintain Python 2.7 past its EOL, which is mentioned in the original email: "support exceptionally important non–security critical applications, if their upstreams don't manage to port to Python 3 in time". However, if there are others who think they have a better approach to handling the EOL (or are willing to pick up the regular python2 package maintenance, rather than moving to a python27 "legacy" package as is planned), then the Python team wants to alert them to its plans. Viktorin expresses some skepticism that folks outside of the Python SIG will truly be in a position to take over, but doesn't want to foreclose that possibility.

This is not the first time that Fedora has discussed the switch. Back in August 2017, we looked at a discussion of where /usr/bin/python will point in a post-python2 world. Other distributions are grappling with the issue as well. A year ago, it was discussed on the debian-python mailing list (and again in August 2017), it is on the radar for openSUSE, and it recently came up for Ubuntu, as well. Each is working out how to highlight the problem areas for Python-2-only packages in their repositories and to make the switch to Python 3 smoothly. We will be seeing more of these kinds of discussions, across the Linux world (and beyond), as time ticks down to 2020.

The switch from Python 2 to 3 is a huge job; one might guess that it is orders of magnitude larger than anyone had anticipated back in the heady days of Python 3000 (around 2007, say). That is a testament to the popularity of the language and the various tools and frameworks it has spawned; it also likely serves as an abject warning for other projects that might ever consider a compatibility break of that nature. In the mid-late-2020s, with the transition presumably well behind them, the Python core developers (and community as a whole) will be due for huge sigh of relief. But it will take work all over the free-software world, including by distributions like Fedora, in order to get there.