About cabal and compatibility [Was: simplifying user hooks (non-backward-compatible)]

[Robert Dockins]

[snip]

> This would greatly simplify the Distribution.Simple.UserHooks
> structure bringing it from 34 fields to 14 fields, or so.
>
> Downsides: Making pre and post hooks would now be slightly harder, and
> it would break existing hooks-using code.

I just want to mention that these kind of changes represent represent a VERY 
big problem. I discussed that issue at some length in an email I intended to 
send to this list very recently, but it seems to have gotten lost. 

So, to recap:

Suppose Alice writes a project A with a Cabal build system that relies on user 
hooks?  Now the interface changes.  Bob writes a Cabal build system using the 
new user hooks for project B.  Alice doesn't have time or inclination to 
update her build system (it still works right? Besides, Alice wants to work 
on project A; she doesn't want to rewrite her build system every time the 
cabal folks have a new good idea).  Now Jow (Debian package maintainer/gentoo 
haskell user/whatever) wants to build both projects A and B.  What version of 
Cabal should Joe have? How does he know how to enable the correct versions 
for which packages, and what versions of which packages?  Ugh! What a 
nightmare.

The interesting thing is that cabal seems to solve the versioning problem for 
most every library except itself!

The solution:

I suggest that the cabal team very seriously consider using the Eternal 
Compatibility in Theory method to manage interface change.

http://www.haskell.org/tmrwiki/EternalCompatibilityInTheory

Rob Dockins