brainstorming ways to stabalize Cabal interface?

[Duncan Coutts]

On Wed, 2006-01-18 at 22:57 -0800, Isaac Jones wrote:
> Greetings.  I'm keen to try to stabalize more of the Cabal interface,
> but I'm not sure the best way to go about that.  I started a wiki page
> to start to document what is stable and what is not.  Eventually this
> should move into the end-user documentation:
> 
> http://hackage.haskell.org/trac/hackage/wiki/StableInterfaces
> 
> Does anyone have clever ideas for how to go about pushing these
> interfaces toward stability?  Do we just need to declare that certain
> things are unstable for the near-term (and possibly implement the
> eternal compatibility in theory idea[1]) and continue to experiment
> with them until they seem done enough?  Do we stare at them very hard?

An idea I've suggested before:

Add another (thin) layer.

The problem as many people have noted is that Haskell source code in the
form of Setup.lhs is quite brittle in the face of changes to the Cabal
API and the .cabal file format.

Often the first sign of trouble is that Setup.lhs just doesn't compile
or if it does it complains that it cannot parse the .cabal file because
there is a new field being used that the current Cabal version being
used doesn't grok. Neither of these situations provide good error
messages or any suggestion to the user of how to proceed.

So my suggestion is that we add a thin layer over the current user
interface:
runhaskell Setup.lhs <command>

instead we should use a little *program*, lets call it "hs-pkg" for now:
hs-pkg <command>

These commands should be the same as for Cabal's Setup.lhs. This program
will basically deffer to the existing mechanisms to compile the package
but it will be able to do many more checks than the user can.

It can read the .cabal file and discover which API version of the Cabal
package is required. For the case of ghc it can then check that the
required version of Cabal is actually installed and invoke runghc
specifying the exact version required.

It can do something about the issue of multiple compilers/interpreters
and the runhaskell program (that John Mecham has pointed out before).

Existing systems already do similar things and are more reliable as a
consequence. For Gentoo distro-packages of Cabal packages it doesn't
just run runhaskell and hope that the right packages are currently
exposed. It invokes ghc with the right -package Cabal-1.1.x flag. This
allows it to deal with packages that require different versions of the
Cabal library.

As a side note, this also allows the Setup.lhs file to be left out
entirely when it just does the default stuff, since the hs-pkg program
can deal it.

Duncan