Re: state of the art in python/alternatives

[Julio Merino <jmmv%NetBSD.org@localhost>]

On Tue, Apr 6, 2010 at 6:58 PM, Greg Troxel <gdt%ir.bbn.com@localhost> wrote:
>
> I realize why it's wrong of people to expect 'python' to exist, because
> it's not stable (interface wise) and programs that use python really
> have to bind to a particular version at build time.  But there are lots
> of things out there that either don't understand or don't believe this.
>
> By default, pkgsrc seems not to create /usr/pkg/bin/python, but I
> understand there is some ALTERNATIVES thing that can be made to do it.
> If that is done, what is the plan for managing dependencies so that as
> python changes from 2.5 to 2.6 that packages properly appear stale (and
> unsafe_depends).

ALTERNATIVES is something targeted to the *user*, not for the packages
to rely on.  I.e. no package should rely on a specific alternative
being selected (because as you say in this case, choosing one version
or another is not a user preference: it is a preference of the
package, which needs a specific interface).  The packages themselves
should explicitly call a particular pythonX.Y executable.

> As an another way around this, what about having a python-bare package
> that is at version 2.6 that depends on python2.6 explicitly.  Then
> people that need to accomodate programs that demand "#!/usr/bin/env
> python" works can install it.  (Of course, we should still fix such
> python-using programs in pkgsrc, and send the fixes upstream.)

That's what ALTERNATIVES are for.  In this case, we are assuming you
are running a Python script that is not packaged, right?  Then, this
script may pick up the /usr/pkg/bin/python symlink, but that's not
something a package should do.  (Once this software is packaged, then
the calls to Python get fixed to point to the correct version, and
that information is hardcoded in the built package.)

-- 
Julio Merino