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