Sergio Talens-Oliag wrote:
Hello all, I was reading the last messages to the list and I've noticed that all python packages I have are pure python and I that I could install them for all python versions (at least for python >=2.3), but if I install the code on /usr/lib/site-python/ the code will only work with the current python version and the multiple package solution looks an overkill, as some people said.
This is not entirely correct; they will work for all versions of python, but will have a few minor uglynesses;
1) any time something in /usr/lib/site-python is imported by a version of python different to the version used to compile the *.pyc's (typically the default version of python), the *.pyc file will be re-compiled. Provided the user it is running as does not have write access to /usr/lib/site-python, the old *.pyc's, will not be over-written. This introduces a mild overhead every time.
2) any time something in /usr/lib/site-python is imported by a non-default version of python running as root, it's *.pyc will be re-compiled using that version of python and over-written.
Provided only the default version of python is used, or that only non-root users run other versions of python this is not a problem. Even if the *.pyc's do get over-written, it is not a serious problem, and most people would never notice.
My proposal for those cases is simple: why don't we remove /usr/lib/site-python/ from the python path and link the contents of that directory on /usr/lib/pythonX.Y/site-python/ on the postinstall of pure python packages that install their code on /usr/lib/site-python/? With this system, when a new pythonX.Y package enters the archive it can build his own linked version of /usr/lib/site-python/, leaving the compiled files on /usr/lib/pythonX.Y/site-python/. The main advantage is that the package is available to all installed python versions and supports zero work transitions.
[...]
Of course all that should be elaborated and formalized a little bit to enter into the Policy document, but I would like to know what do others thing about it and know what other solutions or changes have been proposed for the next version of the policy, if any.
This is exactly like the proposal already described but not yet supported in the current Python Policy. The only difference is it suggests using /usr/lib/python/site-packages instead of /usr/lib/site-python.
The only reason this is not yet supported is no-one has yet made it work. The closest thing is the work done on python-central...
-- Donovan Baarda