brainstorming ways to stabalize Cabal interface?

[Simon Marlow]

Duncan Coutts wrote:
> On Wed, 2006-01-18 at 22:57 -0800, Isaac Jones wrote:
>> Greetings.  I'm keen to try to stabalize more of the Cabal interface,
>> but I'm not sure the best way to go about that.  I started a wiki page
>> to start to document what is stable and what is not.  Eventually this
>> should move into the end-user documentation:
>>
>> http://hackage.haskell.org/trac/hackage/wiki/StableInterfaces
>>
>> Does anyone have clever ideas for how to go about pushing these
>> interfaces toward stability?  Do we just need to declare that certain
>> things are unstable for the near-term (and possibly implement the
>> eternal compatibility in theory idea[1]) and continue to experiment
>> with them until they seem done enough?  Do we stare at them very hard?
> 
> An idea I've suggested before:
> 
> Add another (thin) layer.

[ good idea deleted ]

So there are basically three approaches we can take to mitigating the 
backwards compatibility problem with Cabal.

  (1) Just declare what we claim to be stable, and try to get
      people to update their packages as necessary

  (2) EternalCompatibilityInTheory for Cabal only

  (3) Provide multiple versions of the Cabal package, with
      a wrapper program to invoke Setup.lhs as Duncan suggests

I think we should do at least 2 or 3, because 1 is likely to cause too 
much pain for end-users.  Many packages will need to use "unstable" 
parts of the interface just to work properly, so it's unfair to make 
them second-class citizens.  As far as possible, we should ensure that 
packages keep working for as long as we can support them.

In the past I suggested 2, but I think I'd be equally (or perhaps more) 
happy with 3.  To compare 2 and 3:

   - it seems a bit strange to use ETC just for Cabal, but I don't
     support doing it for everything (it's too heavyweight a solution)

   - 3 requires us to provide multiple versions of the Cabal package,
     rather than one version that supports multiple interfaces.  This
     is perhaps less work for the Cabal developers (keeping the old
     interfaces working is easier, we just compile the old code), but
     it means more bloat.

   - 3 lets us do away with Setup.hs when it is just boilerplate

   - 3 means an upheaval in the end-user's view of Cabal.  They have to
     run "cabal build" (or whatever) instead of "runhaskell Setup.hs
     build"

   - the wrapper program can transparently compile Setup.hs instead of
     interpreting it each time, which is a lot faster

I think I'm coming down on the side of Duncan's suggestion, despite the 
fact that it's a pretty big interface change.  We could migrate slowly 
by making 'runhaskell Setup.hs' emit a warning for the time being.

Cheers,
	Simon