The Linux Foundation

 
LsbPython

From The Linux Foundation

Revision as of 19:24, 5 July 2007 by Stewb (Talk | contribs)

(diff) ←Older revision | view current revision (diff) | Newer revision→ (diff)

Contents

Python for LSB

Python is a LsbInterpretedLanguage, so it will need to address those general issues.

What are the developer issues that might be helped by some sort of standard? Some we've seen are:

  • Some code requires a specific version of Python, but it's not always possible to install that version as "the" Python. For example, Red Hat and Fedora have a tight coupling between a lot of the sysadmin tools and Python, and can't upgrade to a new version (meaning a 2.3 -> 2.4 type transition). The LSB project itself has encountered this: bzr (the new scm tool) requires Python 2.4 but not all developer machines (e.g. RHEL4) have it. When using an alternate Python, how can we be sure all the right pieces get picked up, and by the right interpreter?
  • Because of the previous issue, some software (for example Zope) bundles a copy of Python with the application. The potential of lots of copies of Python on one system seems less than ideal.
  • It's hard to distribute a distro-neutral "binary" package (rpm, deb, etc) with Python-compiled files as .pyc files are version-specific and in addition typically have to go into a path that includes /usr/lib/pythonX.Y which means if you built the package for a different Y the code will never be looked at by the default Python! The .pyc issue can be solved by just installing the .py files, and "compiling" as a postinstall step, but then there are files not managed by the package manager, which distros consider to be a problem.
  • Much python code is installed via python setup.py install (instead of as a full package-manager package). This will default to an install location (/usr/lib/pythonX.Y) that will be correct for that platform, but technically is an FHS/LSB violation - it's not going to /opt. Also, many sysadmins are nervous about the need to pull-from-the-net and install (as root) packages that don't look like carefully checked/signed distro or vendor packages.
  • Code not installed into the system location need some sort of mucking with PYTHONPATH. Like PATH for apps installed into /opt/<vendor>/foo, there really isn't a reliable way to make sure from the install that this works for users. You can tell them to do some setup, or manually fool with /etc/profile.d files, but this is not optimal.

In theory at least, there are three different Python interpreters that can run on Linux: CPython, Jython, and IronPython. The latter two are not quite as full-featured as CPython. Do we limit our standards to accomodate them?

Extension/Embed ABIs

Extending Python by writing C-language modules requires using the Python extension API/ABI. This may be problematic if the extension ABI is not stable; it is reported that it changes at least a bit even for minor releases, as well as changing depending on how Python is built by the distribution. One way it can change is in unicode support, for example some distributions configure for UCS2 while some configure for UCS4.

Python makes it easy to embed the interpreter - that is, link in a library version of the Python interpreter so that it can be used directly by the program or offered as the program's scripting language. Does this have portability issues? Does the resulting package end up needing a library that must be installed on the system?


Paths

Module paths are clearly an important issue for Python. We may need to mandate that a standard module path (/opt/lsb/lib/python?) be supported for extensions.

Perhaps the pth convention would be useful here.

Existing Specification

A pretty good library reference is here

Links

2.4 vs 2.5 Module list differences

Comparing the suggested list of required modules against 2.4.x and 2.5.x:

2.5 (mandriva 2007.1):
[stew@presario30 pythonspec]$ for mload in `cat /opt/lsb/share/appchk/lsb-python-modules.list`;do python -c "import $mload";done 2>&1 | grep 'No module'
ImportError: No module named dl
ImportError: No module named imageop
ImportError: No module named rgbimg
2.4.2 (SLES10):
presario30:/opt/lsb/test/python # for mload in `cat /opt/lsb/share/appchk/lsb-python-modules.list`;do python -c "import $mload";done 2>&1 | grep 'No module'
ImportError: No module named _ast
ImportError: No module named _types
ImportError: No module named _ctypes
ImportError: No module named _curses
ImportError: No module named _elementtree
ImportError: No module named _functools
ImportError: No module named _hashlib
ImportError: No module named _lsprof
ImportError: No module named pyexpat
ImportError: No module named spwd
ImportError: No module named _struct

RHEL5 the same SLES10 - except pyexpat is present

Distribution Version Survey

Distribution Python Version
Mandriva CS4 2.4.1
Mandriva 2007.1 2.5
Debian 4 2.4.4
RHEL5 2.4.3
FC6 2.4.3
SLES10 2.4.2
Ubuntu 6.10 2.4.4c1

Proposed LSB Specification

Specification

Runtime Test

noarch rpm
source rpm
bzr

Application Test

noarch rpm
source rpm
bzr


[Article] [Discussion] [View source] [History]