[EMAIL PROTECTED] (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 <[EMAIL PROTECTED]>
