Re: Proposal: Reorganizing Python for Python2 (and fixes for the previous proposal)
jerome.marant@free.fr (Jérôme Marant) writes:
> And thanks to a small change in the interpreter, the current version
> looks for modules in /usr/lib/python/<version>/site-packages and
> then /usr/lib/python/site-package. Other modules are invisible.
Note that there is no change to the interpreter necessary to achieve
this. Debian Python installations already search in both
/usr/lib/python<version>/site-packages and /usr/lib/site-python for packages.
I would like to make a counterproposal regarding how to handle the
issue of compiling .pycs for multiple versions:
It seems rather cumbersome that all version independent packages would
have to be recompiled every time you switch python versions. That's
fine if we are looking at the use of /usr/lib/site-python as a way of
avoiding duplication of packages in the archive -- but what if you
wanted to have both versions of Python on the system, and actually use
them both? (I am in that position, personally.) Also, we should
probably not forget that this problem may not be limited to just
Python 1.5 and 2.0 --- there is also jpython, stackless, perhaps
even python.net, and it might eventually be desirable to have all of
these installed side-by-side with separate sets of library modules.
A solution to this may already have presented itself, though: perhaps
we should look at what the emacsen maintainers have done, when faced
with a very similar problem. I propose implementing something similar
for Python (and I'm even willing to work on it, if I can get a bit of
free time in the next week or two).
Essentially, this would mean that there would be a python-common
package which provided a bit of infrastructure that could be used by
any python interpreter. Add-on packages that aren't version-specific
would put their python source in a common location
(eg. /usr/share/python/site-packages), and register themselves using a
script in python-common; this script would invoke each Python
interpreter on the system to compile the source, and drop the
resulting .pyc/.pyo in an interpreter-specific directory
(eg. /usr/share/python/<version>/site-packages).
On the other side of this, the interpreters would all provide
"python-interpreter" and would register themseleves on installation,
so that the python-common scripts could compile or remove all the
add-ons.
The /usr/bin/python executable would be a link managed by
update-alternatives. If any other package needs a specific version of
Python it should use /usr/bin/python1.5 or /usr/bin/python2 or
whatever.
Of course, add-ons with .so modules would necessarily be compatible
with only one interpreter, and could not use this system -- so I'm not
sure how useful it would be, unless the add-on maintainers don't mind
splitting their packages into a pure-python part and a compiled part.
One other interesting possibility comes to mind: if we have such
infrastructure in place, it might be possible to enable automatic
installation (even compilation of .so's) of packages that use the
distutils. If distutils usage becomes common (and I see no reason why
it wouldn't) this could enable Python users to install upstream
packages with the full support of the Debian infrastructure, without
waiting for someone to package them as a .deb.
--Rob
--
Rob Tillotson N9MTB <robt@debian.org>
Reply to: