how GNU stow is complementary rather than alternative to distutils

[Zooko Wilcox-O'Hearn]

On May 10, 2009, at 11:18 AM, Martin v. Löwis wrote:

> If GNU stow solves all your problems, why do you want to use  
> easy_install in the first place?

That's a good question.  The answer is that there are two separate  
jobs: building executables and putting them in a directory structure  
of the appropriate shape for your system is one job, and installing  
or uninstalling that tree into your system is another.  GNU stow does  
only the latter.

The input to GNU stow is a set of executables, library files, etc.,  
in a directory tree that is of the right shape for your system.  For  
example, if you are on a Linux system, then your scripts all need to  
be in $prefix/bin/, your shared libs should be in $prefix/lib, your  
Python packages ought to be in $prefix/lib/python$x.$y/site- 
packages/, etc.  GNU stow is blissfully ignorant about all issues of  
building binaries, and choosing where to place files, etc. -- that's  
the job of the build system of the package, e.g. the "./configure -- 
prefix=foo && make && make install" for most C packages, or the  
"python ./setup.py install --prefix=foo" for Python packages using  
distutils (footnote 1).

Once GNU stow has the well-shaped directory which is the output of  
the build process, then it follows a very dumb, completely reversible  
(uninstallable) process of symlinking those files into the system  
directory structure.

It is a beautiful, elegant hack because it is sooo dumb.  It is also  
very nice to use the same tool to manage packages written in any  
programming language, provided only that they can build a directory  
tree of the right shape and content.

However, there are lots of things that it doesn't do, such as  
automatically acquiring and building dependencies, or producing  
executables for the target platform for each of your console  
scripts.  Not to mention creating a directory named "$prefx/lib/python 
$x.$y/site-packages" and cp'ing your Python files into it.  That's  
why you still need a build system even if you use GNU stow for an  
install-and-uninstall system.

The thing that prevents this from working with setuptools is that  
setuptools creates a file named easy_install.pth during the "python ./ 
setup.py install --prefix=foo" if you build two different Python  
packages this way, they will each create an easy_install.pth file,  
and then when you ask GNU stow to link the two resulting packages  
into your system, it will say "You are asking me to install two  
different packages which both claim that they need to write a file  
named '/usr/local/lib/python2.5/site-packages/easy_install.pth'.  I'm  
too dumb to deal with this conflict, so I give up.".  If I understand  
correctly, your (MvL's) suggestion that easy_install create a .pth  
file named "easy_install-$PACKAGE-$VERSION.pth" instead of  
"easy_install.pth" would indeed make it work with GNU stow.

Regards,

Zooko

footnote 1: Aside from the .pth file issue, the other reason that  
setuptools doesn't work for this use while distutils does is that  
setuptools tries to hard to save you from making a mistake: maybe you  
don't know what you are doing if you ask it to install into a  
previously non-existent prefix dir "foo".  This one is easier to fix:  
http://bugs.python.org/setuptools/issue54 # "be more like distutils  
with regard to --prefix=" .