tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: state of the art in python/alternatives

On Tue, Apr 6, 2010 at 6:58 PM, Greg Troxel <> 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

Home | Main Index | Thread Index | Old Index