Re: Experimental Python packages

[Neil Schemenauer <nas@python.ca>]

dman wrote:
> I think the admin should be able to choose which python implementation
> is referred to by /usr/bin/python independent of which python (or
> python-base if you prefer) packages are installed (the alternatives
> mechanism may be a good idea for this).  There can be any number of
> reasons why an admin would want a certain implementation to be the
> default.  These reasons could include 
>     o   understanding a certain version & knowing it works (before
>         upgrading and finding unexpected breakage)
> 
>     o   Jython or Stackless

Why can't the system admin use /usr/local/bin/python?  Using
alternatives for /usr/bin/python is a stupid idea.  I quote Joey Hess:

    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!

I think Python and Perl are similar enough that this advice applies.
Also, I respect the Perl packagers enough to heed their advice.

  Neil