Specifying dependencies on Haskell code

[Duncan Coutts]

On Fri, 2008-05-02 at 09:55 -0700, David Roundy wrote:
> On Sun, Apr 20, 2008 at 09:22:56PM +0100, Duncan Coutts wrote:
> > In the initial discussions on a common architecture for building
> > applications and libraries one of the goals was to reduce or eliminate
> > untracked dependencies. The aim being that you could reliably deploy a
> > package from one machine to another.
> > 
> > We settled on a fairly traditional model, where one specifies the names
> > and versions of packages of Haskell code.
> 
> Do you actually have any precedent for such a system?

I would count all the distro packaging systems as precedent. There are a
few others but those are the most significant.

> I've never heard of one, but then I've been sort of sheltered, due to
> living in the linux world where there is a distinction between
> packagers and upstream authors. I consider this a useful distinction.

I agree it is a useful distinction. I was a packager for gentoo for
three years. The jobs have roughly the same goal -- to deliver great
software to users -- but there is certainly a different focus.

> But that's probably because I'm lazy, or perhaps because I care about
> my users--and thus like to give them options and reduce the
> dependencies of my software.

We are actually very lucky to have people doing the packaging job for
us. It takes time and because of that only the most important bits of
software get packaged.

If we could significantly reduce the amount of time that packing people
have to spend on each package then we could increase the number of
packages that could benefit.

So that's what Cabal's model of specifying dependencies is for, to
provide enough information to enable package management. Without that
information provided up front the packaging people have to spend much
more time manually discovering the dependencies by reading through
README and configure.ac files.

With Cabal packages we have the possibility of generating distro
packages automatically. Several distros have tools to do this automatic
translation. This is something that is essentially impossible with
autoconf. When we started using our translation tool in Gentoo we were
able to increase the number of packages we provided by an order of
magnitude.

Of course we do not expect every little Haskell package to appear in
every distro but the information provided by packages makes it possible
to provide package management (in the form of cabal-install) even for
the packages that do not meet the popularity or QA standards for the
distros.

> I know there is a long history of the autoconf-style approach being
> successful.  Can you point to any success stories of the approach chosen
> for cabal?

Again I'd point to all the package management systems. If you want
examples of build systems that provide enough information for package
management then admittedly there are fewer. Ian already pointed out
Python eggs and Ruby Gems. I think CPAN also has some method for
tracking dependencies though I don't know if or how CPAN modules specify
dependencies.

Duncan