Thoughts on Hackage and the Haskell Platform

I just watched this video of the discussion on the future of Haskell from the Haskell Symposium.  I wanted to write a response on a series of points made about Hackage, the Haskell platform, and the need for a Debian-model “unstable” or a development level of releases.

When comparing Hackage and the Haskell Platform to the Debian model, it’s important to realize that Debian does two things, and there’s no compelling reason, in general, to intertwine them.

• The first is packaging.  Packaging includes putting everything together so that it’s all available from the same place, declares its dependencies on other packages, and is easily downloaded and installed onto the system.  Haskell’s solution to packaging, of course, is Cabal, Hackage, and cabal-install.  It’s an excellent system — easy to use, and quite versatile.  (Debian’s system, apt, is also excellent, by the way.)

• The second issue is integration testing and quality assurance.  This is the part that says we make sure that all the different packages work together nicely, don’t have incompatible version dependencies, that A doesn’t depend on some old behavior of B that recently got changed, and so on.  In the Haskell world, GHC used to do an ad hoc job of this for a few commonly used packages, in the form of extralibs… and now the Haskell Platform is attempting to solve these issues.

People talking about adopting a Debian-like model are, in general, talking about the quality assurance picture.  It’s important to keep in mind the role played by various pieces in this correspondence.  For instance, Hackage — from a quality assurance standpoint only — is actually playing the role of upstream.  Don’t look at Hackage as if it were analogous to Debian unstable.  It’s not!  Packages may get put onto Hackage with no intention of ever becoming a part of the Haskell Platform.  Uploading a package to Hackage does not incur any sort of continuing obligation to maintain that package for future GHC versions.  It just means that someone might see my description and it’s Cabal properties, and that should they want to install my package they can do it easily with cabal-install.  It’s rather important, to me, that Hackage remain that way.  Otherwise, we may sadly see developers hesitating to put their packages on Hackage for fear of the maintenance obligation.  That would be quite a disaster.  (As Duncan mentioned in the video linked above, a sort of non-centralized community moderation may be a good thing in Hackage; e.g., ranking packages by downloads or dependencies.  These would be for user information only, and would not negatively impact someone who uploads a package.  User ratings are a tougher question; they would need to be on a per-version basis to avoid penalizing developers for uploading early… and that may well make ratings useless in the long run, as any new release would essentially wipe them clean.)

Where the Debian model is more worthy of discussion, then, is not so much in Hackage, but rather in the Haskell Platform.  There it might actually make some sense, off in the future, to separate an unstable versus a stable version of the Haskell Platform.  (I doubt we’ll see so much activity in the near future that we have any need for an intermediate testing stage as Debian has now, especially since many of the basic packaging problems can be resolved in Hackage prior to accepting the packages into the Haskell Platform anyway.)  A beta release of the Haskell Platform could well be something worth doing in the long term.

Ultimately, though, I think the main thing is to remember that: (a) the Haskell Platform is far and away better than what we had before this point, and (b) a lot of smart people will be watching what happens, and the community will learn a LOT about quality assurance and blessing of collections of libraries in the next year, and that will help the community make better decisions going forward.  So I guess, in the end, I think things are going in the right way, and hope people continue to keep their eyes and ears open, and be patient so that we can learn from the process instead of going in assuming that we’ve got all the answers.