Extending the dependency syntax

[Duncan Coutts]

On Thu, 2005-07-28 at 14:23 -0700, Isaac Jones wrote:

> 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.

There is a tension here between the needs of the package authors and the
needs of the packaging systems. And it affects the language that
packages are written in.

A declarative system that provides lots of information is what the
packaging systems want. So they know all dependencies and can have
flexibility over building and deploying packages (to do things like
build in a protected sandbox, or to build a binary package on one
machine and install it on another).

Package authors might want more of a complete programming language that
allows them to to whatever is needed to build install and register their
software.

The downside of the latter approach is that it is nigh impossible to
make a native package that follows the policies of the native packaging
system (like not running arbitrary scripts/programs on the target or
build machine with root privileges).

My own personal opinion is that cabal/haskell packaging can be made the
most sucessful if we take advantage of the native packaging systems and
so make it possible to automate as much as possible the process of
wrapping a cabal package into a native package. I think we will reach
the greatest audience by this approach.

Duncan