New Cabal and cabal-install releases

Tuesday, 17 June 2008, by Duncan Coutts.
Filed under coding.

Cabal-1.4 and cabal-install-0.5 are now released!

If you were already using a pre-release of cabal-install then you can just:

$ cabal update
$ cabal install cabal-install

The Cabal library

There are no huge new features in the Cabal library itself. The main new feature is that is supports a significantly improved version of cabal-install. Cabal-1.4 does have a number of incremental improvements and lots of bug fixes. You can see the full list in the changelog.

So the most exciting thing is the release of cabal-install...

New features in cabal-install

Command line improvements

The most immediately noticeable thing is that the command line interface now has all the commands that runhaskell Setup.hs has. Of course it still has the features to download and install packages from hackage. It also gained an upload command. So it now provides a command line interface to the whole Cabal/Hackage system. There's no need to use runhaskell Setup.hs ever again. There is also bash command line completion support included which I find is a great time saver.

Installing and upgrading

The next big thing is that it includes a new package dependency resolution system that finds correct and sensible solutions more of the time and has better default behaviour. The new behaviour should be similar to other package managers that people are used to.

For example, suppose you've got xmonad-0.5 installed and version 0.7 is the latest on hackage, then

$ cabal install xmonad

will upgrade to xmonad-0.7.

The behaviour of install is to upgrade as little as possible to satisfy your request, but sometimes you want to upgrade all the dependencies too. Supposing now that we have xmonad-0.7 installed, but we're still using X11-1.4.1 and the latest version on hackage is X11-1.4.2, then

$ cabal upgrade xmonad

will install X11-1.4.2 and re-install xmonad-0.7, this time built against the newer X11-1.4.2.

So in general, the install command will install the latest version of things but will try and use any existing installed versions of dependencies while the upgrade command will also try to use the latest versions of all dependencies. As a special case, cabal upgrade on its own will try to upgrade all the packages that you have installed.

For both command there is a --dry-run flag so you can see what would be installed without actually doing it.

Hugs

Yes, it even works with hugs. That is, cabal-install built by ghc can manage the installation of packages for hugs. In principle cabal-install should be able to be run by hugs but currently the zlib binding is using a function that hugs does not support.

Note that for hugs, Cabal does not know what packages are already installed because there is no equivalent of the package database that ghc has. So that means cabal-install cannot do very sensible installation planning. It should work ok so long as all the dependencies are already installed.

Windows

Yes, it even works on Windows. The one caveat is that cabal-install cannot currently upgrade itself because Windows makes it hard for a process to overwrite its own executable file. It needs more complex trickery with the Win32 API. In the meantime the workaround is to rename the cabal.exe file first eg to cabal-foo.exe, then say cabal-foo install cabal-install.

Build reporting

One feature that made it into this release is build reporting. cabal-install keeps logs of all packages that you install (at least packages from hackage, not local ones). It records a bit of information about each package, in particular whether the outcome was successful or not. You can see these build reports in ~/.cabal/packages/$server/build-reports.log.

The plan in the longer term is to let people upload these build reports to hackage so we can get a wider range of testing data about the packages on hackage.