Re: Proposal: Reorganizing Python for Python2 (and fixes for the previous proposal)
Rob Tillotson <robt@debian.org> writes:
> 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'm glad to see that my post is making people react and think about
valuable solutions. The purpose of my post was to setup bases for
a discussion. Sure, it is far from being the best solution.
> It seems rather cumbersome that all version independent packages would
> have to be recompiled every time you switch python versions. That's
However, It is strange to periodically switch from one version to another.
> fine if we are looking at the use of /usr/lib/site-python as a way 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
That is the one that came to my mind but I didn't have a look to it.
> 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).
I can help too.
> 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).
Right.
>
> 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.
Are you allowed to install multiple versions of a package that
provides the same package? How does the system handle this?
>
> 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.
I agree.
>
> 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.
They'll be installed in the interpreter specific directories.
We may have to split packages between .so and pure python, so the first
one would be installed without being registered.
> One other interesting possibility comes to mind: if we have such
...
> waiting for someone to package them as a .deb.
I agree.
--
Jérôme Marant <jerome.marant@free.fr>
http://jerome.marant.free.fr
Reply to: