[Python-bugs-list] Python 1.6a1 - installation report (PR#263)

[François Pinard]

Guido van Rossum <guido@python.org> writes:

> And you specified /usr/local/stow/python-1.6a1 as the (exec_)prefix, right?

Yes.

> it seems you'll be using a different prefix for each version of each
> app then.  This is not the assumption that the install script makes,

Of course.  The idea behind Stow is to install each package in its own
hierarchy, while compiling it to run elsewhere (in `/usr/local' usually).
Stow then (cleverly) establishes symbolic links between `/usr/local' and
where the package has been really installed.  This allows for quick and
easy un-installation of packages, and also for quick and easy switching
between installed versions.

Automake and Autoconf support Stow, but unofficially, from the fact that
one can do:

   ./configure --prefix=/usr/local

and

   make install prefix=/usr/local/stow/python-1.6a1

without adverse effect.  The missing step, once Stow is available, is:

   cd /usr/local/stow && stow python-1.6a1

Stow is discussed from time to time in the Gnits gang, where Automake
(and many other things :-) have been brain-stormed.  Stow is distributed
by the FSF, and its author was working on a rewrite from Perl to C, the
last time I heard of it.  It is currently distributed by the FSF.

An alternative to Stow is building `RPM's, but these requires more work
than a mere installer is usually prepared to do.  Stow is easy.

> This certainly hasn't come up with Linux installs before, so I wonder
> what is special about Stow, and what kind of problems it is trying to
> solve that makes it important for me to deal with it.

There are many things that can become popular because we did manage to
make room for them, or (I'm not sure the idiom translates in English)
because "we prepared the field".  Autoconf and gettext are good examples,
but there are a lot of tiny and humble things in this case, which have been
prepared for a long time (and often after exhausting discussions :-), and
then became of wider use.  My feeling is that Stow is one of these things
that is worth our favour, also given that once a package properly uses
the Autoconf/Automake machinery, the extra effort needed for Stow support
is small.  I'm not saying it is important, but I think it is a good bet.

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard