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:
/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.
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.
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?
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?
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.
A pretty good library reference is here
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