Re: Proposal: Reorganizing Python for Python2 (and fixes for the previous proposal)
Disclaimer: I don't know much about python. I just want to make sure
that you're not making the same mistakes that were made when perl was
modified so multiple versions could be installed at one time.
> . Python 1.5 was installed and we decide to install 2.0
> python 1.5 specific packages are installed in ...python/1.5/site-packages
> other packages are installed in ...python/site-packages
>
> * we make /usr/bin/python point to python 2 thanks to alternatives
This is where I begin getting flashbacks to the whole perl SNAFU. Is it
possible for a python program to use python 2.0 features and not work
with 1.5? Is it possible for a program to use deprecated 1.5 things and
not work with 2.0? Is it possible some later version of python after 2.0
will introduce new features programs could use?
All of these things were true with perl, and all of them tripped us up
horribly. The problem is, if you have two versions of perl (or python)
installed and /usr/bin/perl(python) is managed with alternatives,
dependancies are useless. A package that uses perl 5.6 (ptyhon 2.0)
features should depend on that package. But a user can install an older
version still, and can modifiy the alternatives to make it the default,
and then the program breaks, even though its alternatives are satisfied.
The only way to make a program that uses perl 5.6 (I'll stop putting the
equivilant ptyhon stuff in parens now :-) reliably work is to make it
use #!/usr/bin/perl-5.6. But this is just shooting yourself in the foot
when perl 5.7 comes out and your package works with it fine except it
refuses to use it because the filename is different.
It's a horrific can of worms, which is why perl in debian is no longer
going to do this at all -- it's just not worth it. I encourage you python
folks to think this through before adopting a similar scheme. Good luck!
--
see shy jo
Reply to: