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