Python2.6And3.0
Launchpad Entry: python-for-jaunty
Created:
Contributors:
Packages affected: python2.6, python3.0, python-defaults
Summary
Introduce new versions of python for the 2.x series (2.6) and python3.0.
Release Note
This section should include a paragraph describing the end-user impact of this change. It is meant to be included in the release notes of the first release in which it is implemented. (Not all of these will actually be included in the release notes, at the release manager's discretion; but writing them is a useful exercise.)
It is mandatory.
Rationale
We'll introduce new python versions and drop older python versions for jaunty, and addressing issues with the current way of packaging of python extensions.
- Python 3.0 introduces language changes and in almost all cases requires different source for 2.x and 3.0. To keep third party modules for 2.x and 3.0 independent on the other python versions, the packaging in a different binary package is proposed.
- The distutils currently packaged with python is configured to install in the same location for manually installed packages and for packages included in the distribution, leading to upgrade problems and inconsistencies in the installations.
- Different packaging tools currently install in different locations, breaking assumptions of upstream software. An upstream package should not behave differently when packaged with a different packaging helper. This includes relative imports, import order of modules and extensions and upstream plugin systems.
- Some packages current have their files installed in package and helper specific directories on the file system, not using the conflict checking in the dpkg and apt packaging tools and deferring this to the python packaging tools. To robustify this, we install files which are not directly installed into sys.path in a common location (/usr/share/pyshared for 2.x, and /usr/share/py3shared), with the prefix /usr/lib/pythonx.y/{dist,site}-packages dropped.
- To handle python transitions more gracefully, we currently package third party modules in a way which is independent of the python version, not adding the support for a specific python version as files/symlinks in the package itself, but creating this support during package installation. Depending on the packaging tool this is either incomplete or seen as scary. During installation a python module is not available for use. Robustify the packaging so that a module is already usable after unpacking and no action (besides byte-compiling) is needed.
- Provide a common way to handle so called namespace packages using the tools already available in the distribution (diversions).
- Removing support for one python version currently leads to uninstallability of packages and requires rebuilds of depending packages (extensions). Packages needing a python version which is not the default should handle these dependencies themself, and not burden the archive with housekeeping.
Use Cases
Assumptions
Design
Python 2.6
The upgrade to 2.6 as the default python version is a bit easier than the update from 2.4 to 2.5. 2.6 didn't see that many changes on the extension site as 2.5 did have. The upgrade should be done in two steps:
- 1) Build extension and modules for 2.6 as an additional supported python version. 2) Make 2.6 the default python version. 3) Optionally drop support for python 2.5 in jaunty.
Python 3.0
A python 3.0 module has different source code than for 2.x. Our current helper support doesn't support different source code for one module that well, and package and installation sizes do increase. Package modules for 3.0 in binary packages python3-foo to be used for python versions 3.x. The binary package for 3.0 can be built out of the same source package, but doesn't have to.
Installation locations
Currently /usr/lib/pythonx.y/site-packages is used for installation of python extensions and modules, plus an additional directory /usr/local/lib/pythonx.y/site-packages, the latter conflicting with the site-packages with a python installation with --prefix=/usr/local.
- Use /usr/lib/pythonX.Y/dist-packages for the installation of all public modules and extensions included in the distribution. Add a new option to distutils --install to install into this location (--install-layout=deb).
- Use /usr/local/lib/pythonx.y/dist-packages for the installation of locally installed modules and extensions to be used with the python included within the distribution. This is the default location when using distutils.
Names for these directories discussed with Martin v. Löwis and Barry Warsaw; the names are not perfect, but we did want to stick to the same directory in /usr and /usr/local.
Python 2.4
Drop it, but what to do with applications still needing it? E.g. zope2.x, plone.
Implementation
- Helper tools (dh_py*):
- Search for stuff in dist-packages and do the right stuff.
- Add options to include the symlinking in the package.
- Extend support for python3.x
Code Changes
Code changes should include an overview of what needs to change, and in some cases even the specific details.
Unresolved issues
This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.
BoF agenda and discussion
Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.