On Sat, Sep 01, 2007 at 05:20:23PM +0100, Claus Reinke wrote:
lets have a look at that base package example, for a change: if the remainder had been called base-core and base had become a proxy package that provides no functionality other than recording the new dependencies needed to get hold of the old functionality, by depending on the spin-off packages, then there wouldn't have been any externally visible changes to base, old code depending on base would still work as long as base was installed, and new code could bypass base, using base-core and other spin-off packages directly.
That wouldn't work, as packages can't re-export modules. And even if they could, this method would be very awkward. This is about the third time that base has shrunk, and hopefully not the last. This protocol would leave us with some rather awkward names. Fortunately the damage is limited. Module interfaces have largely observed the kind of stability you're asking for, it's just which packages contain those modules. So the needed change is confined to one line of the .cabal file. It's a pain to support different versions, but Thomas has just extended Cabal to make this much easier.
same for cabal: if it learns to do new things, do old things in nicer ways, or interpret more information, *that should not affect any old code*. if old code breaks, that means that old information is no longer accepted, old dependencies are no longer sufficient, or old functionality is no longer provided.
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.