Hackfoofery

Alson Kemp

2009: The Year Of Hackage

Haskell (even with the GHC extensions) seems pretty stable, but the greater GHC platform seems pretty unstable. I’ve already written about how we’re [sorta] missing a vital part of the tool chain (it was broken when I tried to build it using 6.10 the other day), but in this post I’ll focus on Haskell’s libraries (especially user generated ones).

After fairly heavy usage of Haskell over the past few months, I exit 2008 thinking that, while Haskell is a wonderful language, the library situation with GHC prevents GHC from being more heavily used. Unless you’re writing completely custom software, it can be very difficult to try a piece of Haskell software. One of the reasons Rails is so successful is that it Just Installs and the tutorials are Just That Easy. OTOH, when I start to install a new package in GHC, I never quite know what will happen.

Here are some problems I’ve had with Haskell’s libraries over the past few months/years along with possible fixes for those issues:

  • Hackage != Haskell Library Repository: Hackage doesn’t necessarily contain the latest and greatest versions of a library. For example, harp on Hackage is V0.2, but harp on code.haskell.org is V0.4.
    • This could most easily be fixed by automating the pulling of code from repos. Since harp is located at code.haskell.org/hsp/harp, Hackage could automatically pull code and build packages from there.
    • The Hackage team has put together a great system. It seems fair that they have T.O.S. which keeps Hackage usable and clean. Part of the TOS would be that a package maintainer: keep the package up to date in Hackage; respond to e-mails; notify the Hackage team if the maintainer is abandoning the package.
  • 6.10 ‘base’ Library Reorg: the base library reorg looks good, but it changes around a lot of the … er … basic libraries of the system.
    • Not sure of a fix here. Seems like a nice reorg and if base weren’t reorged, I’d probably be bitching about the need to reorg base… Here’s to hoping we don’t go through another base reorg any time soon.
  • Bit-rotted Libraries: Libraries exist in Hackage which won’t build and which will probably never build. For example, HaskellDB is an awe-inspiring library… that hasn’t built since 6.6 and just isn’t going to build any time soon. As a newbie looking for a database library, HaskellDB would be the obvious first place to look and trying to use it would produce serious frustration (it certainly did for me). It’s nice to have a historical reference to HaskellDB in Hackage, but the package shouldn’t be listed as currently usable. Maybe it’d be sufficient to default to filtering by the latest GHC version.
    • Given Don’s post, it might not be too difficult to script weekly library builds and auto-email library maintainers about their library being broken. After a few missed e-mails, the library could be shifted to another maintainer or, at worst, deprecated.
    • Gripe about git as much as you like, but GitHub has done a great job of building an environment for ‘social coding’. Using something like GitHub would make it easy to: allow those-who-want-to-work-on-a-library to do so; move a package to a new library maintainer; provide a consistent location from which Hackage could pull code. FWIW, Rails has gone this direction…

Summary

Haskell is an awesome language. I’m a big fan (as evinced by Turbinado). Working with Haskell has forced me to think about coding in a new way and has seriously improved my coding ability. However, Haskell has also proved enormously frustrating as I try to put together a project which depends on many libraries.

A great way to increase the visibility and usage of Haskell is to make it easy to develop and build complex software in Haskell. Naturally, that requires a robust set of user libraries and that seems to require Hackage. So let’s make 2009 the Year of Hackage.

Updates

Over on reddit, Don suggests we make “2009: the year distros start supporting the platform”. enauv replies that “[GHC is] too radical and changes too quickly for platforms to truly support it.” I tend to agree with enauv, so much so that this post was originally titled “2009: GHC 6.10 LTS?” because GHC (the overall platform) does tend to change too quickly for distros to support it effectively. Maybe GHC needs to migrate GHC to Long Term Support and move bleeding edge stuff to GHC 7.0?


This post is written by a practicioner and not by an academic. I understand that Haskell is an ‘academic’ language, but Haskell has gotten popular enough that it’s no longer ‘academic’ and that’s the greatest compliment a language could receive.


How am I going to solve the library dependency problem in Turbinado? I’m going to bundle all libraries on which Turbinado depends into Turbinado. Not a solution I like, but it’s one that works…

Written by alson

January 1st, 2009 at 10:24 pm

Posted in Haskell

with 6 comments

6 Responses to '2009: The Year Of Hackage'

Subscribe to comments with RSS or TrackBack to '2009: The Year Of Hackage'.

  1. I think automatically pulling from development repositories to hackage is exactly the wrong thing to do in terms of stability. Perhaps if hackage supported different “streams” (stable/unstable) it might make more sense but there’d still be issues with version numbers and the like as people don’t bump the version number with every single checkin.

    Ganesh Sittampalam

    2 Jan 09 at 8:01 am

  2. As for haskelldb: I’m using it with GHC 6.10.1. I fixed the cabal files and some imports in the source files of the haskelldb package and three of its dependencies and it works. But I didn’t contact the package maintainers yet and I think I shouldn’t upload the packages to hackage without contacting all of them first…

    frederik

    2 Jan 09 at 11:26 am

  3. Ganesh,

    I tend to agree, but there’s got to be a happy middle ground. See Frederik’s comment: here’s someone who could contribute, but is looking for an easy way to do so. Something like GitHub would allow him to update his repository very easily and the Hackage team could decide that his repo represents the current released version. Not a perfect solution, but then Haskell is a young-ish language and can’t necessarily adopt Debian’s development framework yet…

    Frederik,

    Really!? Color me impressed. I’ve had similar experiences with libraries and have usually decided not to go through the hassle of figuring out how to ship patches back. That’s why I’m sorta-advocating the GitHub thing, which would make it very easy to send your patches back to your own ‘forked’-version of the library. Thereafter the maintainer could pull the patch or the library could be switched to pull from your ‘fork’.

    Unless you’re sending back your patches, I would still vote that HaskellDB be marked as only functional with GHC 6.6. I firmly believe that, once someone dips their toe into the Haskell swimming pool, they generally get turned off by the difficulty of building libraries.

    alson

    2 Jan 09 at 1:44 pm

  4. nixos.org has functional package management system that essentially versions all the deps together

    dragan gajic

    13 Jan 09 at 10:12 am

  5. [...] also: 2009-The Year Of Hackage and A Plea For [...]

  6. I am in a similar situation – i sometimes fix packages from hackage for my own use but i have not figured out a convenient way to feed back the changes. for example, i would have saved time when the fix on haskelldb were in hackage when i searched for a haskell db connection (i use now HDBC).

    i method with keeping fixes contributed but not yet tested separate from the ‘unstable’ last version of the developers, but still making them available in hackage when required would be helpful.

    another solution could be to automatically add a wiki page to every package; contribution (fixes) could then be put there and would be available to others running into the same problems.

    andrew u frank

    6 Sep 09 at 6:54 am

Leave a Reply