ANNOUNCE: cabal-install 0.5

[Duncan Coutts]

cabal-install 0.5
=================

cabal-install version 0.5 is out:
http://haskell.org/cabal/download.html

or get it from hackage:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/cabal-install

If you are already using a cabal-install pre-release then you can just:
$ cabal update
$ cabal install 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 install xmonad-0.7. The older version, xmonad-0.5, will remain
installed.

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 run 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.

For example, there is one from my machine for xmonad:

        package: xmonad-0.7
        os: linux
        arch: x86_64
        compiler: ghc-6.8.2
        client: cabal-install-0.5.1
        flags: -testing small_base
        dependencies: X11-1.4.2 base-3.0.1.0 containers-0.1.0.1
                      directory-1.0.0.0 mtl-1.1.0.0 process-1.0.0.0
                      unix-2.3.0.0
        install-outcome: InstallOk
        docs-outcome: NotTried
        tests-outcome: NotTried

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.


Duncan