On Sun, Jan 14, 2001 at 02:10:25PM -0800, Joey Hess wrote: > Moshe Zadka wrote: > > s/posible/certain/ > > Python 2.1 already contains many features future programs will be > > able to use. (It's not out now, but alpha is supposed to be released > > in a few days) > > > OTOH, all Python programs in Debian *should* work with 2.0. If they > > do not, then they have a bug -- and it should be fixed. > > So, as a Perl basher <wink>, I think Python will not cause the same > > problems that Perl did. > > You mean all python programs will work with 2.0 until 2.1 is out and > programs start using its features. At that point every problem I predicted > is going to bite you. > Exactly. Unfortunately, I don't think there *is* an easy way to make this problem disappear completely. Really, all python scripts should have some way of declaring what they require, such that /usr/bin/python could examine them and choose an appropriate interpreter. I have a sneaking suspicion that such an animal is "beyond the scope of this discussion" :). My 2c (of course, I've proably missed something which will bring the whole house of cards down :) - * Forwards incompatability: very few Python programs should break with newer versions of Python (I don't know how this compares to perl); the only reason this should not become a bug against the program in question is the "GPL breakage". So another possible solution is: create /usr/bin/python-gpl-compat; programs which require GPL compatability can be identified and moved over to this interpreter (ie #!/usr/bin/env python-gpl-compat). These programs then depend on python-gpl-compat, which could be a virtual package provided by the python version 1.5 which containins the symlink. Once this is complete, python can move to version 2, and python-gpl-compat can become a real package. Python v2 can conflict with the old versions of all the GPL-requiring packages, and old vesions of packages which are known to break with v2... All python extension which function with both v2 and gpl-compat can start providing .so files for both (okay, it wastes a bit of disk space...). Eventually, upstream for these will start using v2-only features, at which point the package splits into a frozen gpl-compat snapshot and the original marches on. To resolve the dependency problems, any python code using /usr/bin/python-gpl-compat should depend on (initialy virtual) python-extension-gpl-compat packages. Of course there is still Jpython and stackless python, but if I understood it correctly nobody was suggesting that /usr/bin/python might become one of these? -- Peter Eckersley http://www.cs.mu.oz.au/~pde (pde@cs.mu.oz.au) TLI: http://www.computerbank.org.au <~~~~.sig temporarily conservative pending divine intervention~~~~> GPG fingerprint: 30BF 6A78 2013 DCFA 5985 E255 9D31 4A9A 7574 65BC
Attachment:
pgpfOHVupPhLp.pgp
Description: PGP signature