[Distutils] The $0.02 of a packager ;-)

[Martijn Faassen]

Greg Ward wrote:
> 
> Quoth Oliver Andrich, on 04 February 1999:
> > This is fine to hear. Is it also planned that I can check for a certain
> > version of library or so? Let's say I need libtk.so.8.1.0 and not
> > libtk.so.8.0.0 or is this kept anywhere else? How do you like to 
> > implement this tests?
> 
> No, that's not in the plan and it's a known weakness.  Checking
> dependencies on Python itself and other Python modules should be doable,
> so that's what I think should be done.  Open the door beyond that and
> you fall into a very deep rat-hole indeed -- a rat-hole that RPM takes
> care of quite nicely, and you argued very cogently that we should *not*
> duplicate what RPM (and others) already do!

Actually there was some discussion of an 'external dependency' system.

The idea is that we'd like Python extensions to check for some common
libraries that they rely on. For these common external libraries (or
programs) we could provide standard modules that simply check if the
library is there (and return true or false or some failure message). 
Initially the distutils package could supply external dependency modules
for some libraries (such as for GNU readline). Eventually the developer
or packagers could start to supply these things (we could initiate a
central archive for them or bundle them with the distribution so other
developers or packagers don't have to reinvent the wheel). After that,
the developers of these external libraries themselves might start
providing them. :)

An external dependency checking system could be as simple or complicated
as one likes. A simple system would simply check if libfoo.1.5 is there.
A more complicated system might look for libfoo.1.5 and upwards. The
simplest system ever is when it automatically gets installed when
libfoo1.5. is installed -- doesn't need much checking code then. :)

What probably is out of scope is autoconfig style behavior; if we can't
find libfoo, we are still able to use libbar to provide the same
functionality. Unless this somehow follows easily from the design, we
shouldn't aim for this.

Anyway, this was just discussion. We haven't worked out the implications
of a external dependency system fully yet. How useful would it be? How
platform independent would or should it be? How do the external
dependency modules get distributed? With distutils? With distutils
packages? With the external libraries? Where these external dependency
modules stored?

The advantage of Python is that we have a full fledged programming
language at our hands to do configure style things. This can make things
more messy, but it can also definitely make some things trivial that are
hard to do with make like systems (especially if there are some suitable
Python modules that help). We shouldn't be *too* scared of rebuilding
configure functionality; we shouldn't be too worried about
developers/packages having to learn yet another make language; it'd just
be Python and if there are enough batteries included it shouldn't be
hard.

Regards,

Martijn