Alson Kemp


A Plea For “cabal install”

with 13 comments

Updated per Ganesh’s comments.

Over here, Adolfo commented:

“Hi,I tried to do follow the example, but I couldn’t even install the packages, hsx and hs-plugins were impossible. I tried with cabal and manually, and neither of those worked . any suggestion, known issue with this packages?”

I’ve been busy adding features to Turbinado and haven’t circled back around to making sure that it’s easy to build, so I can claim a lot of the blame for the build problems.  Turns out to be really important that publicly released packages are easily buildable…

Thinking back, I have really struggled to build Turbinado… and I wrote Turbinado!  Turbinado depends on some particular bugfix-ish library releases (e.g. GSomething 0.6.1). With GHC 6.10, a bunch of libraries have broken or have changed so much that they badly break Turbinado. (I need to specify better the versions in turbinado.cabal.)

At times, I’ve considered bundling the dependencies into Turbinado so that building Turbinado would be easy, but that’s always felt like a cop-out. So I’m pleading for “cabal install”. Given Turbinado’s dependence on particular versions of libraries, I would love to able to do:

cabal install turbinado
  OR  (from /home/alson/turbinado)
cabal build

Cabal Install

Most casual users of Ruby, Python, Perl, Java, etc, know that those languages have automagic build/dependencies system (respectively, gem, eggs, CPAN, maven). The tools may be of varying quality, but many tutorials include something like “First, use GEM to install the package: gem install rails” and demonstrate just how simple it is to get a useful piece of software installed.

This is not the case in Haskell. I’d guess that no more than 5% of Haskellers know about the cabal command line tool and “cabal install”. On the other hand, I’d guess that 95% of novice Rubyers know about “gem install”. These automated build/dependency system are now critical to the success of languages. As a beginner in Ruby, I always knew that I could easily try out various libraries by using GEM to install bits of software. I’m now fairly experienced with Haskell and, partly because of that experience, I don’t believe that I can easily try out various Haskell libraries.

Niklas Broberg’s HSP is a great example of the challenge of building Haskell programs. HSP is very nicely separated into modular libraries which: makes it easy to apply pieces of HSP’s functionality to a program; makes it hard for a human (at least for me) to build any one part of HSP because each part depends on so many other parts. A build/dependency tool would make HSP much easier to build into existing programs.

The Plea

I love using Haskell and Haskell will only get better if more people are able to use it. IMO, a pre-condition to the growth of the language is a solid, easy to use build/dependency system. Cabal is that system for GHC and the cabal command line tool is a key part of that system.

Unfortunately, the cabal command line tool isn’t bundled with GHC, but … Please get it, build it, use it, report any bugs, compliment the Cabal team, etc. It’ll be a great help to the Haskell community.

darcs get
cd cabal-install

Update: Haskell Platform

Ganesh points out the Haskell Platform Proposal, so it looks as though there is a plan to incorporate the cabal command line tool. See the following:

P.S. Anyone know if the cabal command line tool is going to make it into GHC?

Links to cabal install information:

Written by alson

December 26th, 2008 at 4:43 pm

13 Responses to 'A Plea For “cabal install”'

Subscribe to comments with RSS or TrackBack to 'A Plea For “cabal install”'.

  1. I understand the plan is for the tool to be part of the Haskell Platform, which will also contain GHC and will be something that people are encouraged to get instead of “raw” GHC.

    Ganesh Sittampalam

    26 Dec 08 at 8:59 pm

  2. Ganesh,

    Good to hear. In my limited googling I hadn’t seen that. Updating the post…



    26 Dec 08 at 9:03 pm

  3. As a newbie to Haskell coming from the Ruby world, the first question which popped into my mind (after “how the hell do you do I/O”, that is :P) was “what’s Haskell packaging system?”

    I immediately installed Cabal after installing GHC, and I started using it right away. While I found it similar, in some ways, to rubygems (possibly better, because you seem to have only one centralized online repository?), I am currently missing two things:

    • Less dependency conflicts (I tried installing Yi, but it was complaining that two different versions of bytestring were required by gtk2hs and Yi)
    • Automatic download of dependencies. Maybe it’s there, but I couldn’t find it. In rubygems, all required packages are now downloaded by default, but apparently this is not so in cabal (or at least I didn’t find the appropriate option, yet :P), and I had to download all required pakages one by one.

    I really hope Cabal takes off as it should, really… It will be very good for Haskell, I believe.

    Fabio Cevasco

    27 Dec 08 at 8:18 am

  4. Fabio,

    Funny. I’ve tried to build Yi, too. I don’t think that I had much luck either! 😉

    On deps: I think that “cabal install” does handle dependencies, but it only does so on install. Thus far, I don’t think that you can do “cabal build” and have dependencies tracked down and built (which I would love for use with Turbinado).



    27 Dec 08 at 9:19 am

  5. Why does it install in ~/.cabal by default?. I want a root level install shared by all users. How about /usr/local or /opt/local? Maybe this is possible, but it’s not obvious or the default.


    27 Dec 08 at 9:55 am

  6. @Alson Yes, I was kind of “expecting” cabal to download and build all the dependencies for me 🙂 Actually, writing a script which does so shouldn’t be too hard (at least a very rudimentary one)…

    I had a very brief look at Turbinado, and it seems promising. I can’t wait to see if you come up with a proper (and simple) ORM.

    Fabio Cevasco

    27 Dec 08 at 9:59 am

  7. Fabio,

    I can’t wait to see if I come up with a proper ORM, either… I’m a generalist so I’m kinda hoping that I can get the ORM to a reasonable state so that someone who’s smarter can take and run with it…


    I was wondering the same thing the other day. My assumption had been that the cabal command line tool would be installed wherever GHC was installed (~/bin or /usr/local/bin). I’m not sure why that isn’t the case, but the deviation from expected/default behavior won’t help adoption of the tool. I assume that the Cabal team chose to install in ~/.cabal for a reason… I just don’t know what the reason is…



    27 Dec 08 at 10:25 am

  8. You guys know that cabal install acts basically the same for installing from a directory and installing from Hackage, right?
    ie. ‘cabal install yi’ fetchs and builds and installs dependencies for yi just as ‘cd ~/bin/yi && cabal install’ (where ~/bin/yi is obviously the repo) would.


    27 Dec 08 at 6:50 pm

  9. gwern,

    I definitely know how to install Haskell packages, but, as with many other languages, it’s much easier and more enjoyable to automate the process. Turbinado has the following dependency list (many of which are built into GHC) and making sure that you have just-the-right versions installed is not fun…:

                           base < 4.0, 
                           harp == 0.4, 
                           hsx == 0.4.5, 
                           HTTP < 4000, 



    27 Dec 08 at 8:01 pm

  10. Fabio.
    you’re probably confusing (since it’s easy..) Cabal the library and cabal the executable, which comes in the cabal-install package, since the latter does download all the dependencies and build them automatically, either by “cabal install foo” or running “cabal install” in a directory with a .cabal file

    see the –global options, it’ll install packages in the global packagedb and under /usr/local by default, see also –prefix and –root-cmd, or cabal install –help in general.

    tried building yi from the darcs repo?


    28 Dec 08 at 4:15 am

  11. Saizan,

    I tried building Yi a couple of years ago… Probably should have checked the project again before commenting since the project looks to be very alive. I’ll try to build it again.

    Also, thank you for the note about “cabal install” pulling in dependencies. I would expect “cabal build” to do the same, too, no? But it doesn’t…



    28 Dec 08 at 5:27 pm

  12. […] 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 […]

  13. […] See also: 2009-The Year Of Hackage and A Plea For Cabal-install […]

Leave a Reply