brainstorming ways to stabalize Cabal interface?
simonmarhaskell at gmail.com
Thu Jan 19 05:50:40 EST 2006
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:
>> 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) 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
- 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.
More information about the Libraries