FoundationsQPythonVersions

Shipping only Python 3 on the 12.10 CD

For many cycles Ubuntu developers have been working on a migration to Python 3. This has taken modest steps leading up to 12.04, with many packages (primarily libraries) getting Python 3 versions upstream, into Debian, and into Ubuntu. Python 3 is not distributed on the Ubuntu 12.04 CD images though, but major milestones have been reached, such as the porting of dbus-python to Python 3.2.

It is a release goal for Ubuntu 12.10 (Quantal Quetzal) that we ship only Python 3 on the desktop CD images. Don't worry, Python 2.7 will still be available in the archive, and more specifically 'main' for now. But we want all libraries and applications on the desktop CD (or more specifically, those packages with Task: ubuntu-desktop (also minimal and standard) to be running on Python 3.

The ultimate goal is really to relegate Python 2 to universe for 14.04 LTS.

The Q-series blueprint exists for planning the UDS-Q session, holding work items, etc.

This Google document captures the set of packages and leaf applications that still need packaging or porting as of Ubuntu 12.04. This list was generated with the oncd.py script from this branch. WE NEED YOUR HELP!. Some packages have Python 3 support upstream but are not yet packages for Ubuntu. Others do not yet have Python 3 support. In those cases we must either help the upstream to land Python 3 support or rewrite our applications to not require the unported dependency.

Spreadsheet legend:

  • white background - status unknown or Python 3 version currently unavailable
  • yellow background - Python 3 version available (or nearly so) in upstream and/or Debian. May need Debian packaging/update, or sync to Ubuntu
  • blue - Canonical/Ubuntu is the upstream. This doesn't mean you can't or shouldn't help port it, just that we know who to lean on at crunch time. Smile :)

  • green background - Python 3 version now available in Ubuntu!
  • dark gray - Will likely go away in 12.10
  • red background - Python 3 port likely impossible due to upstream orphan, resistance, or infeasibility

(See the Status column of each package for additional details.)

Rationale

  • Python 2 is EOL upstream. Python 2.7 is the last Python 2 that will ever be released. There will never be a Python 2.8.

  • While Python 2.7 is officially supported upstream for bug fixes until 2015, and probably longer for security fixes, in reality, the enthusiasm will wane considerably before then for upstream to continue to maintain Python 2.7 when all the good stuff is happening in Python 3.
  • We don't want to have to actively support Python 2.7 after the next LTS.
  • Porting to Python 3 is a multi-cycle, disruptive, change. Best to do this immediately after the last LTS (i.e. 12.04) so that we have plenty of time to shake out problems before the next LTS.
  • If we wait to switch to Python 3, the costs do not magically go away. A few more packages may be ported by then, but by driving this effort now, we can improve the overall momentum to Python 3, speeding up the arrival of the tipping point.
  • Doing ports now allows us to develop strategies for success, both from a language POV and a platform POV, which we can communicate to others, multiplying the positive effect and thus quality of all libraries undertaking the port.
  • Driving the ports ourselves allows us to identify issues in Python that uniquely affect the Debian/Ubuntu platform. We thus have the opportunity to effect changes in upstream Python 3 (since it can't happen in Python 2) that improve the robustness of our Python platform (e.g. PEP 3147, PEP 3149, and PEP 420.

  • Moving to Python 3 allows us to finally deal with the pain of Unicode errors in non-English locales in a much more principled way (rather than sheer luck and liberal cargo cult sprinkling of try/excepts Smile :) )

  • Gives us an opportunity to clean up tons of technical debt incurred in code we've written as old as Python 2.3.
  • We can take advantage of all the new features and modules in Python 3, where all the new development is happening.

Plan

The plan is to identify a handful of desktop applications included on the default install, follow their dependency stack, and investigate whether their upstreams already support Python 3 (either in a released version, a development branch, or fork). For those which have no upstream support yet, we have several choices:

  • Find an alternative that does already support Python 3
  • Encourage and help upstream to do the port
  • Port it ourselves and contribute to upstream
  • Fork or rewrite from scratch

Candidates for Python 3 porting:

  • Software Center (LP: #823254)
  • Update Manager
  • Jockey
  • gwibber backend
  • Computer Janitor

There is no plan to make Python 3 the default /usr/bin/python. See for upstream policy on this.

Side Effects

Even though this task is ostensibly to port only those packages on the desktop CD, it will have some effects on other flavors and installations. For example, once Ubiquity and Update Manager are ported, all flavors will have to ship the Python 3 version, meaning they will probably end up shipping both Python 2 and 3 (consuming some additional disk space).

Also, there is an impact on optional software. A good example are the Suggests for duplicity, which add some optional behavior. These packages (e.g. python-boto, python-cloudfiles, python-paramiko) are not seeded on the desktop CD, so aren't in the critical path for porting, but not having them would reduce the functionality of the parent tool. In these cases, we would still like to have Python 3 ports, and in the spreadsheet above, you'll see them listed under "Good to Have".

It is indeed true that this means /usr/bin/python will not exist on a fresh install from desktop CD until it's installed explicitly, or implicitly by way of an unported dependency. /usr/bin/python3 will exist though.

Known blockers and issues

  • If we're to carry multiple versions of Python 3 (e.g. 3.2 and 3.3), how does dh_python3 handle situations where modules don't support all supported Python 3 versions? This is unsolved, although often discussed in debian-python.
  • Namespaces (not PEP 382 or 402 though; Eric Smith's as yet unreleased new PEP)
  • xapian
  • gstreamer

Warning: Ubuntu Software Center currently plans to stay on Python 2.7. dbus and xapian are the main blockers to moving to Python 3. Talk to Michael Vogt for more details. —mpt

@mpt: current version of dbus-python in Ubuntu supports python 3. –mitya57

Resources

Python 3 packaging

Python3 packaging is covered in this packaging best practices guide. However dh_auto-* doesn't yet support Python 3. There's was a Debian GSoC project to write a new tool before fixing dh (python-multibuild tool to be later integrated). It needs work (Piotr in debian-python is leading this now). Until this lands, we should just continue using overrides in the meantime. Distutils packages can override these easily, however other packages may be non-trivial.

Historical reference

As mentioned, we've actually been working on this spec since the Maverick days. Here is some historical information from the whiteboard:

See also this wiki page for detailed background:

Full UDS-O session notes: http://pad.ubuntu.com/uds-o-foundations-o-python-versions

Python/FoundationsQPythonVersions (last edited 2012-06-01 15:44:50 by mail)