About cabal and compatibility [Was: simplifying user hooks
robdockins at fastmail.fm
Sat Dec 10 18:26:53 EST 2005
> 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
The interesting thing is that cabal seems to solve the versioning problem for
most every library except itself!
I suggest that the cabal team very seriously consider using the Eternal
Compatibility in Theory method to manage interface change.
More information about the Libraries