Cabal package descriptions

[ross at soi.city.ac.uk]

On Fri, Feb 11, 2005 at 09:21:53AM -0000, Simon Marlow wrote:
> The GHC 6.4 release is way overdue.  We originally planned to push it
> out in Aug last year, and it's now been over a year since the last major
> release of GHC!  I suppose given that, another couple of weeks won't
> hurt :-)

Cabal also needs to get out to a wider user base as soon as possible.
Days should be enough.  It will be a beta release, but I think that's
inevitable.  With the changes just merged to 6.4 (the preprocessor hook
and the package description changes) I think we've made all the changes
to the interface that we can foresee at the moment.  But I'm sure that
once the people recently exercised by filepaths and time start using
Cabal there will be many more.

Bug fixes can go in minor releases.  There may well be one of those
before too long.

> What is important, as I see it, is that the version of Cabal we ship
> with GHC 
> 
>   - can support building & registering 3rd party packages for 
>     some time to come
> 
>   - will be compatible with future enhancements to Cabal.
>     That is, packages which work with this version of Cabal will
>     also work with future versions (maybe until the next
>     *major* release of Cabal, at least).
> 
> So the second point means that the syntax we use for .cabal files, and
> the Distribution.* API, have to be supported for some time to come.  We
> should be clear about which parts of the Distribution.* API are actually
> supposed to be stable, BTW.

So for .cabal files, future expansion can add new fields or generalize
the syntax of existing fields.  Supporting the existing fields for some
time seems possible.

As for the API, I'd suggest a minimal approach: promise to keep the
simplest setup scripts working, namely defaultMain, defaultMainWithHooks
and defaultUserHooks (but not the internals of the UserHooks type)
and to preserve the constructors of the License and Extension types.
Everything else should be marked as experimental.  Any non-trivial
setup script will likely have to change in future, because there is
very little experience with writing them.  The API could do with
more Haddock documentation, though.

sdist is documented as broken -- we can leave it at that for now.
Package authors can handle tar or zip.

The makefile route hasn't had much use -- that can wait too.