Ross Paterson
On Thu, Jan 19, 2006 at 09:35:32AM +0000, Duncan Coutts wrote:
I'm keen to try to stabilize more of the Cabal interface, [...] The problem as many people have noted is that Haskell source code in the
On Wed, 2006-01-18 at 22:57 -0800, Isaac Jones wrote: form of Setup.lhs is quite brittle in the face of changes to the Cabal API and the .cabal file format.
Indeed. I think the best hope for stability is to make setup scripts optional, and to seek to reduce the situations where they're needed. The vast majority of scripts are
main = defaultMain or main = defaultMainWithHooks defaultUserHooks
Of course, the setup scripts are only a problem in the situations where they're needed, not in these two situations.
(Incidentally hackage and packages repository contain very few exceptions to this; it seems Gentoo has a much larger collection.) If we were to rely on an external tool like Duncan's hs-pkg, we'd need a field saying which of these (or future ones) to use. We'd also need version numbers for the file format, which might be expected to change less often than Cabal package versions.
Reducing the need for setup scripts involves identifying the missing bits people are working around and implementing general facilities. Eliminating the boilerplate scripts will help, if only by flagging the packages of interest.
The missing bits of cabal? I disagree. I don't think we should eliminate the setup scripts. There will always be special things that folks need in their build system, and they will want a general facility for them, such as the setup script or the multiple scripts you mentioned. I don't think that continuing to make cabal more complex is the answer. There are definitely some things it should do that it doesn't do now, but if we abandon the setup scripts, then we will have to always put everything into cabal itself. We should instead try to stabalize the cabal interface and put the complexity into the layered tools. Stable hooks should solve the problem of the Setup scripts not compiling, and having a cabal-version field and a more flexible parser should solve the problem of new or unknown fields. We've done hardly any work in these directions. I think we should at least try these approaches. peace, isaac