Re: Proposal: Reorganizing Python for Python2 (and fixes for the previous proposal)
jerome.marant@free.fr (Jérôme Marant) writes:
> > 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.
Well, it's not a matter of switching, really -- it's a matter of
having multiple versions of the interpreter installed at the same time
and being able to use any of them at any time.
(You can import the same modules from both versions, as long as the
code will run in both. It's just that it will not use the .pycs if
they were compiled by the wrong version, so it will try to recompile
them on every import, which defeats the whole point of having .pycs.)
I develop almost exclusively in Python, both for my job and for
everything else, so I naturally have a lot of Python add-ons
installed. I cannot simply jump to 2.0, if for no other reason than
that I have to work with products where that decision isn't up to me
to make. So naturally I would like to have all of my favorite stuff
available for both Python versions.
Right now, I am forced to maintain two copies of a lot of stuff: one
copy installed from Debian packages for Python 1.5, and another copy
installed from upstream source for Python 2.0. I would rather not
have to do this, if there is a nice technological solution available.
Another place where this could occur is on a multiuser system, where
different users use different Python versions. There, it seems like a
poor solution to force the admin to choose which Python will have good
performance, and which will have to recompile stuff on every import.
(This is not just a matter of what /usr/bin/python points to -- it is
a matter of what happens even if you explicitly pick a version, if
that version isn't the one the .pycs are compiled for.)
> > 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?
Yes, that's what virtual packages are for. Just to clarify: you can't
have more than one version of a real package on the system, but you
can have multiple real packages that provide the same virtual
package. So we would still have separate packages like python-base
and python2-base which contained the actual code; these would
"Provides: python-interpreter". Then, other stuff that just needs a
Python interpreter without requiring a specific one, would have
"Depends: python-interpreter".
The advantage of this over something like "Depends: python-base |
python2-base" is that it is easily expandable to support more
implementations of the same thing, without needing every other package
depending on it to change. (I find it quite conceivable that we could
eventually have three, four or more Pythons to choose from -- 1.5 and
2.0, perhaps jpython or stackless or whatever comes after 2.0, maybe
even python.net. Some developers might need to have all of these
available at once, even though most people will just get by with 1.5
or 2.0, just like some systems need all four emacsen while most people
just pick one.)
--Rob
--
Rob Tillotson N9MTB <robt@debian.org>
Reply to: