Extending the dependency syntax

[Isaac Jones]

"Simon Marlow" <simonmar at microsoft.com> writes:

> So here's a strawman proposal to address some of the use cases raised
> recently[1] that Cabal doesn't currently support well.  This is just a
> first attempt; I expect we'll need to make changes or start over if we
> discover cases that it doesn't handle.

(snip proposal)

Lots of this is stuff I've been wanting to ad at some point.  I think
that rather than overloading the build-depends field, we should add a
new field for tool dependencies; otherwise, we could get name
conflicts between the two and such.

I'm not positive that the simple build infrastructure would be able to
take all of the information in the tool-dependendencies into account;
for instance, discovering the version of happy and ghc might be a bit
tricky and error prone.

(snip)
> ----------------
> name: mylib
> version: 1.0
> exposed-modules: My.Lib
> build-depends: 
>   base>=1.0 
>   (ghc>=6.4 || ghc>=6.2 [ghc62] || hugs-any [hugs]) 

Debian has something like this, where you can specify optional
dependencies.  I've always planned to implement something like this
for Cabal.

At the same time, I think we need to be careful not to re-invent make
and re-invent dpkg / rpm via feature-creep.  I understand Duncan's
desire to have absolutely everything automated for gentoo without the
gentoo packager having to intervene, but that's just what the OS
packagers have been dealing with for every language.  I want Haskell
to be easier than other languages (historically, it's been harder) but
if we make the package syntax more and more complex, I think we run
the risk of expending a lot of energy for a small amount of benefit by
creating a whole new language for packages.

OTOH, maybe Haskell can become the generic packaging language, and
people can start to use it to package everything... if anyone can
create that, the Haskell community can ;)

I'd really rather see the expansion of Cabal features going in a
different direction: the Distribution library.  Wouldn't it be great
to have an embedded domain-specific language for packaging / building
inside Haskell?  Then the setup script could be like the sane man's
makefile.  As Hudak (I think) points out in a paper on embedded
domain-specific languages, many languages grow from DSLs (like the
.cabal file) into general-purpose languages.  The reason I like the
setup script is so that we don't have to keep expanding the .cabal
file; we have all the power of Haskell at our fingertips in the Setup
file.

For Debian packages in most languages, we have a hunk of executable
stuff for building and installing, and a relatively small amount of
metadata to deal with dependencies and what-have-you.  I think we
should try to stick to that model wherever possible, of course,
improving upon Debian where we can.

I'm not saying that Simon's ideas can or should be implemented in the
Setup script; but that's just something to think about when we're
talking about expanding the .cabal file syntax.

> [ghc62]
> other-modules: Compat.Ghc62
>
> [hugs]
> other-modules: Compat.Hugs

Here we're starting to get complicated, though, and I'm a bit scared
of this complication.  Presumably, then you have something in the
source code to optionally #include the correct module?

This is perhaps one of the few places where I'd rather see Haskell
itself altered to address this need than to patch it with Cabal.

Anyway, these are all good ideas, this is just my first reaction and
I'll keep thinking, and we should keep discussing this.  More later.


peace,

  isaac