From The Linux Foundation
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
- Notes from the Austin Sprint, May 2007
- Python document from the F2F in Berlin, Dec 2006 (some of the same issues for Perl)
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 |