We ended up with quite a big group of people interested in various aspects of Cabal, cabal-install and Hackage. So I ended up spending much more time talking than hacking. I'm sure that's a good thing though. Hackathons should be about sharing ideas, brainstorming and experimenting.
I arrived at the hackathon with ideas about three main areas I wanted to get people to work on:
- a make-like dependency framework for the Cabal library
- a package dependency resolver for cabal-install
- cabal-install/hackage build reporting
In fact these are more or less exactly the topics for proposed Google Summer of Code projects, but there's no harm in starting early and exploring possible solutions.
I expounded a bit on the dependency framework issue though we didn't end up working on that in the end. It's actually an interesting research problem. I'll write about it another time.
Josef Svenningsson got interested in the cabal-install dependency resolver issue. He spent much of the hackathon prototyping a BDD-style approach. Hopefully Josef will post his current ideas to the cabal-devel mailing list in the next week or so.
Thomas Schilling (aka nominolo) worked on the last remaining feature we wanted to get into Cabal-1.4. When configuring a package want to be able to specify additional constraints on the versions of dependent packages. As a developer we might want this just to be able to test building a package against an old rather than the latest version of a dependency. The reason we really want it for Cabal-1.4 though is so that we can use it in cabal-install. In cabal-install we want to work out up front exactly how we will configure a whole set of packages. We need a way to get Cabal to configure a package exactly how we wanted it in our global plan, rather than making some local decision. Thomas got this finished and I'll be integrating the patches some time soon.
Lennart Kolmodin (with some help from David Waern and myself) spent quite a while hacking on build reporting in cabal-install. The idea here is that we want to get cabal-install to report build success and failure back to the hackage server so we can discover what packages build in what environments. On the client side most of the work involves information plumbing - gathering information from various places within Cabal to include into a build report. We realised that most of the information for a build report is discovered once we've decided how we're going to configure the package. So we spent most time hacking on some code I'd written previously for representing installation plans and extending it to collect information on the outcome of installation. We managed to get it integrated though it still needs more work because our new InstallPlan type has a much more demanding notion of validity than the abstraction it replaces, so the current dependency resolver needs to be updated to produce valid InstallPlans.