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=" .
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
