RE: Cabal package descriptions
On 10 February 2005 18:39, Isaac Jones wrote:
I'm still a bit worried; I suspect the Distribution.Make stuff is out of date, and if we're under a freeze already then that should probably go away. setup sdist has bitrotted too, and I don't have a hugs test suite yet.
The change I made to add preprocessors to UserHooks is pretty important, IMO.
I can definitely release cabal separately; I have maintained an independent tree, as you know, but there are obviously problems with this. Are we under a code freeze right now? Can we get another weekend to hack on it?
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 :-) 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. Cheers, Simon
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.
participants (2)
-
ross＠soi.city.ac.uk -
Simon Marlow