On Sat, 2007-09-01 at 19:13 +0100, Ross Paterson wrote:
Cabal really is a special case. The API is still much too immature to stabilize, which is why it's handled differently from the other libraries. It was never claimed to be stable. However a package that uses a boilerplate Setup.hs (as 90% of the packages on Hackage do) needs only backwards compatibility of the .cabal format, and that has been carefully preserved. With the recent improvements to Cabal, fewer packages will need the tailored setup scripts that are so fragile. To impose extra constraints on the Cabal API at this point would make it harder to make the wholesale cleanups and enhancements needed to benefit all the other packages, such as Thomas's recent implementation of configurations.
There is a common issue, but it's the "birthpangs of a new package system". Pouring concrete over Cabal in its current state won't help.
I fully agree. We've done a lot of work on Cabal recently fixing a huge long list of bugs, complaints and feature requests. None of this would have been possible without doing lots of refactoring at the same time. Anyone is welcome to look at the internal code before and after too see what I mean. We still need to make significant further internal API changes to keep the code sane, to get features to be implemented in one place rather than spread throughout the code base. So the internal APIs are not stable and we can't promise to make them stable without halting all significant future development. On the other hand we have been extremely careful with not breaking the Cabal file format (and most of the command line interface). It's backwards compatible and in many ways future compatible too (ie adding new fields does not break old versions of Cabal, though it does generate warnings). GHC adopting Cabal for it's library build system has driven many improvements in Cabal but yes has caused quite a bit of breakage in GHC HEAD and the associated libraries. This isn't too bad since we have Ian on hand to keep things in sync. For other libraries using trivial Setup.hs files it's fine. I really don't know what to do to make the base split up easier. The main problem is that there really is nothing that identifies a piece of code as the package or module it lives in changes. The modules in packages can overlap so the module name isn't sufficient, though it's probably good enough in most cases. I've also been guilty of changing the internal api of ByteString, though I do note that it is only the internal api which we never promised to keep stable. The only changes in the public part of the api were as a result of requests and discussion on this mailing list (see unsafe CString bits and renaming .Base to .Internal and .Unsafe to reduce confusion). Duncan