cabal for ghc 6.8.2, package upgrade warnings, please?

[Duncan Coutts]

On Fri, 2007-11-30 at 23:17 +0000, Claus Reinke wrote:
> assuming that ghc 6.8.2 is not too far away, is there
> any chance of cabal becoming a bit friendlier wrt old
> .cabal and Setup files, before that release?

We're pretty much fully backwards compatible with old .cabal files, the
only problem is Setup.hs files.

> you've heard me say before that i'd have preferred
> a backwards compatibility module, but if that isn't
> possible, couldn't cabal at least detect that a .cabal
> file is probably outdated (==not obviously up to date),
> and issue a warning with a helpful url? something like:

This would be great, unfortunately I don't think it's technically
feasible with the current design. At the moment, the Setup.hs is the
first entry point and if that doesn't compile then we're stuffed. We
have no opportunity to offer helpful messages, the user just gets a
deeply unfriendly type error message.

Setup.hs files are allowed to use the entire Cabal api, which includes a
lot of useful stuff but it completely exposes the inner workings. Since
we keep improving the inner workings that api keeps changing. Even the
more public parts place constraints on the implementation that we would
like to lift in future (esp the UserHooks api).

I suppose we could have kept exactly the old api and had it redirect the
defaultMain and related entry points to the new implementation. The
downside is that since the Cabal api is more or less the complete cabal
implementation, keeping the old api and adding a new implementation
would involve keeping the complete old implementation and adding a new
copy. Then repeat for each api revision. Perhaps we should be using
Eternal Compatibility in Theory. However I don't much relish the
prospect of trying to make old apis work in terms of new implementations
or explaining to package builders why they cannot use certain features
with certain packages that use the old library api.

The current approach works about 90%, in that 10% of packages broke in
the transition from Cabal 1.1.6 to 1.2 (according to my hackage survey).

We are certainly going to change the Cabal api again in incompatible
ways, if only to make an api that looks like it was designed as an api
that has a chance of being stable. So we have the chance to plan for a
better transition in future. So if anyone has any feasible technical
suggestions...

> btw, i knew that page existed, but had quite a bit
> of trouble finding it. shouldn't there be prominent
> links to it from cabal and hackage home pages?

Yes, you're quite right.

I've added a link from the cabal website and I've reorganised the page
so it's hopefully rather clearer:

http://haskell.org/haskellwiki/Upgrading_packages

> as in: concerning recent cabal updates (look here
> first if you have trouble with old .cabal packages).
> in the longer term, that could become the start of
> a cabal/hackage faq section..


Duncan