FeistyPythonRoadmap

Revision 3 as of 2006-11-12 20:10:35

Clear message

Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.

Summary

Move on to python2.5 as the default python version, keep python2.4 as supported version, define a policy to package eggs, no more code in /var/lib, revisit supported python packages in main, let the python packages play nice with apt-file and other tools again.

Rationale

  • python2.5 as the default version should be supported by most packages for the feisty schedule.
  • python2.4 should still be supported for applications like zope2.x, which are known to adopt new python versions late.
  • Every module/extension is installed as an egg in 2.5; define a way how eggs are handled in the distribution.
  • Python modules should install into a location, where conflicts/replaces are handled by the packaging tools, not by the python packaging tools (move into a common installation directory, not into a package-specific directory).
  • Do not install byte-compiled files in /var, so that code can be protected by mounting /usr read-only.
  • Revisit the python packages in main, demote/promote packages.
  • To make better use of the debug build, build third party extensions using the refcounting feature turned on.
  • Make a difference between the local/user installation location and the distribution installation location to make upgrades between releases more reliable.

Implementation

Python 2.5 as default

  • In edgy, python2.5 is somewhat supported as a non-default version for modules and extensions, which build using 2.5. Python2.5 support for a large number of modules was disabled; either upgrade to new upstream versions or backport patches to support 2.5 (in main, sip4-qt, python-qt and kde are affected, plus some other modules).
  • Make 2.5 the default after all modules/extensions are available for 2.5, not later than feature freeze.

Keep python2.4

Nothing needs to be done besides applications currently using the unversioned interpreter moving to the versioned python2.4 interpreter name.

Egg support

Eggs try to provide a distribution and installation mechanism; this duplicates to a large extent the apt/dpkg tools used for packaging.

  • We have to ship source packages, which are not supported by eggs.
  • Eggs try to support more than one version of a module/extension, which we try to avoid, shipping only one version of an extension/package.
  • Install all eggs as unversioned eggs.

Installation destinations

  • Add an option --distribution to distutils/setuptools, which installs into a location which is different from the default installation location.
    • Removes version information from the .egg-info name
    • Installs into /usr/lib/pythonX.Y/dist-packages

  • Currently modules packaged to support more than one python version install into /usr/share/.../<package-name>; package tools cannot be used to detect/handle file conflicts any more. Use an installation directory which doesn't have the package name in the path.

Debug builds

  • Add support for debug builds, handling a separate hierarchy /usr/lib/pythonX.Y/debug-packages
    • Needs changes in the python infrastructure tools (i.e. python-central)
    • Needs changes in the packages for which we want to have debug builds (targeting all extensions in main for feisty).

Revisit the python packages in main, demote/promote packages

  • Collect packages for demotion/promotion until Feb 2007.
  • Review this list on the distro meeting in Feb 2007.

Unresolved issues

Maybe split this spec into subspecs, if priorities or milestones differ for the subtopics.

BoF agenda and discussion

This section should be removed before approval; please make sure that everything here has been factored into the specification proper.

  • python2.5 as the default, new upstream versions/cvs snapshots for packages not yet in unstable/not yet released with support for python2.5)
  • packaging eggs (try to come up with guidelines how to package eggs)
  • no more code in /var/lib, currently some python code cannot be made read-only, because it's put into /var.
  • revisit supported python packages in main
  • let the python packages play nice with apt-file and other tools again (currently files are artificially installed in an unique path)
  • define and support a layout for python debug packages using the current python debug builds (with refcounting turned on).

CategorySpec