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