The interesting question of whether Ubuntu 20.04 LTS will include Python 2

April 8, 2018

It's 2018, which means that 2020's end of Python 2 support is only two years away. Two years seems like a long time, but it's not really, especially if you're not a full time developer or Python person, which is our situation. One of the questions about what we have to do about our current set of Python programs boils down to the question of whether Ubuntu's very likely April 2020 Long Term Support release (Ubuntu 20.04) will include Python 2.

So far, Ubuntu has done LTS releases every two years in April; 10.04, 14.04, 16.04, and now the impending 18.04. If they follow this pattern, they will release the next LTS in April of 2020, after Python 2's end of life (which the Python people say is January 1st 2020), and if we follow our usual practices, we'll begin using Ubuntu 20.04 on some systems that summer and autumn. These systems will need to run our Python system management tools, which means that if Ubuntu 20.04 doesn't include Python 2, we need to have our tools running on Python 3 before then.

(Of course it might be a good idea to port our tools to Python 3 now, but there's a difference between being prepared and being forced. This is especially important when you have to prioritize various things you could be working on, which is generally our situation.)

Since Ubuntu 20.04 will be released after the Python 2 cutoff date, in theory it could drop Python 2 on the grounds that it's no longer supported by the upstream developers. However, in practice there are two issues. First, it seems very likely that Python 2 will be supported by other people if problems emerge, because there are other long term Linux distributions that are already committed to supporting systems with Python 2 past 2020 (for example, Red Hat Enterprise Linux 7, which will be supported through 2024, and then there's Ubuntu 18.04 itself, which will be supported through 2023). Second, it's not clear that all packages that currently use Python 2 will be updated to Python 3 in time for 2020 (see eg). Ubuntu could choose to throw Python 2 out anyway and to hell with any packages that this forces out, but that might not be very popular with people.

The current state of Ubuntu 18.04 is that Python 2.7 will be available in the 'main' package repository, directly supported by Ubuntu. One possible option for 20.04 is that Python 2.7 would be available but would be demoted to the community supported 'universe' package repository, which theoretically gives you lower expectations of bug and security fixes. This would give Ubuntu an option to shrug their shoulders if some serious issue comes up after 2020 and no one steps forward to fix it.

Probably the safest option for us is to begin moving our tools to Python 3, but likely not until 2019. If we started now, I'd have to make them compatible with Ubuntu 14.04's Python 3.4.3; if I wait until we've migrated all of our 14.04 machines to 18.04, I get to base everything on Ubuntu 16.04's somewhat more recent 3.5.2.

(Using 3.5 as the base could be potentially important, since the 3.5 changes brought in formatting for bytes and better handling for character encoding issues with sys.stdin and sys.stdout, both of which might be handy for our sysadmin-focused uses of Python.)

Sidebar: Red Hat Enterprise Linux 8 and Python 2

Unlike Ubuntu, Red Hat hasn't officially announced any timing or formal plans for RHEL 8. However, a new version of RHEL is due (based on RH's traditional timing) and there are some signs that one is in preparation, probably for release this summer. I can't imagine such a version not including Python 2, which means that Red Hat would likely be committed to supporting it through 2028.

This isn't necessarily a big burden, because it's my opinion that we're unlikely to find any serious issues in Python 2.7 after 2020. This is especially so if people like Red Hat make a concerted effort to find any remaining 2.7 problems before the official end of support, for example by extensively running fuzzing tools against 2.7 or by paying for some security auditing of Python's SSL code (or doing it themselves).


Comments on this page:

By Ewen McNeill at 2018-04-09 00:40:10:

As a random possibility to consider alongside the two you have: is it maybe feasible to fork your Python 2.7 code at this point, and then have an old Python 2.7-only version and a new Python 3.5+ version? Running the Python 3.5+ version on any system that is new enough to support it, and just running the old Python 2.7 version on the older OS machines until they get upgraded?

Obviously there could be some duplicate work involved there (to change both versions on either side of the fork), but if (a) the rate/volume of change is relatively low anyway, and (b) things like support for new systems/features is only needed in the newer OS version (ie, Python 3.5+) then then the extra work might be relatively small.

That approach would allow doing the porting now, or at least on a more chosen time schedule, rather than putting it off "until forced".

(Another option could be to install a non-system-Python -- via anacoda, virtualenv, etc -- for the in-house software to use, which could be a Python 3.5+; there are people installing Python 3.5 on Ubuntu 14.04 via a PPA which could be another approach -- this appears to be the deadsnakes PPA, which seems to have both Python 3.5 and Python 3.6, as well as a Python 3.7 beta package.)

Ewen

PS: I do agree that it's likely that Python 2.7 will appear in some form in RHEL / CentOS 8, and Ubuntu 20.04, although I'm expecting usage of it will be fairly strongly discouraged by then (if only by bumping it out of the core OS).

By cks at 2018-04-09 00:59:23:

Although I've yet to do a full inventory of our Python code (despite urging myself to do so in 2016), I know that a bunch of it is programs that we run from a central area from cron on all of our systems. Splitting these programs into two versions is possible in theory but too annoying in practice. It's simpler to just let the Ubuntu 14.04 systems age out before I try to move things to Python 3.

(For similar reasons we don't want to try to make system management scripts depend on a custom version of Python 2. We really want them to run on stock systems, because that makes life a lot simpler. And at this point our attitude on 14.04 systems is that the less we have to touch them, the better.)

By Ewen McNeill at 2018-04-09 19:28:04:

See also this LWN article about Python 2 and Fedora (link sponsored by my LWN subscription, so you can read it now; unpayalled in a couple of weeks).

The short version is that there's already discussion about maybe pulling out Python 2 dependencies for Fedora 2019 releases (which are supported nto 2020), and whether that's practical or not. In practice it seems likely to be a gradual "fade out" of support over the next 3 years or so.

Ewen

PS: Yet another thought on migrating: for some simpler Python scripts making them Python 2.7/3.5+ compatible is relatively easy, with a few "from __future__ import ..." lines at the start and a bit of care of choice of features. That might allow running those with both Python 2.7 (older systems) and 3.5+ (newer systems) in parallel, if you had some way to auto-detect which was there (eg, `/etc/alternatives`?).

PPS: Personally the biggest migration issue for Python code I've written is the bits that need to still run on Python 2.6 (eg, older RHEL/CentOS systems with just system Python); that's further from 3.x than 2.7 is.

By Twirrim at 2018-04-10 18:11:21:

Timing being everything, just two days later, RedHat have announced that Python 2 will not be part of RHEL8, by way of the release notes for 7.5. The times they are a changing.

https://www.phoronix.com/scan.php?page=news_item&px=RHEL-8-No-Python-2

Written on 08 April 2018.
« A learning experience with iOS's fingerprint recognition
Power consumption numbers for my 2018 home and work machines »

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

Last modified: Sun Apr 8 22:06:50 2018
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.