Identifying outdated packages in cabal install plans

Every time I build a Haskell package—whether using cabal or cabal-dev, whether something from Hackage or a development version of my own package—I always do a --dry-run first, and inspect the install plan to make sure it looks reasonable. I’m sure I’m not the only person who does this (in fact, if you don’t do this, perhaps you should).

But what is meant by "reasonable"? Really, what I look for are versions of packages being installed which are not the latest versions available on Hackage. Sometimes this is fine, if the package I am installing, or one of its dependencies, legitimately can’t use the most cutting-edge version of some package. But sometimes it indicates a problem—the upper bound on some dependency needs to be updated. (Note that I’m not trying to get into the upper bounds vs. no upper bounds debate here; just stating facts.)

To help automate this process, I threw together a little tool that I’ve just uploaded to Hackage: highlight-versions. If you take an install plan generated by --dry-run (or any output containing package identifiers like foo-0.3.2) and pipe it through highlight-versions, it will highlight any packages that don’t correspond to the latest version on Hackage.

For example, suppose running cabal-dev install --dry-run generates the following output:

$ cabal-dev install --dry-run
Resolving dependencies...
In order, the following would be installed (use -v for more details):
Boolean-0.0.1
NumInstances-1.0
colour-2.3.3
dlist-0.5
data-default-0.5.0
glib-0.12.3.1
newtype-0.2
semigroups-0.8.4
split-0.1.4.3
transformers-0.2.2.0
cmdargs-0.9.7
comonad-3.0.0.2
contravariant-0.2.0.2
mtl-2.0.1.0
cairo-0.12.3.1
gio-0.12.3
pango-0.12.3
gtk-0.12.3.1
semigroupoids-3.0
void-0.5.7
MemoTrie-0.5
vector-space-0.8.2
active-0.1.0.2
vector-space-points-0.1.1.1
diagrams-core-0.5.0.1
diagrams-lib-0.5.0.1
diagrams-cairo-0.5.1

This is a big wall of text, and nothing is obvious just from staring at it. But piping the output through highlight-versions gives us some helpful information:

$ cabal-dev install --dry-run | highlight-versions
Resolving dependencies...
In order, the following would be installed (use -v for more details):
Boolean-0.0.1
NumInstances-1.0
colour-2.3.3
dlist-0.5
data-default-0.5.0
glib-0.12.3.1
newtype-0.2
semigroups-0.8.4
split-0.1.4.3 (0.2.0.0)
transformers-0.2.2.0 (0.3.0.0)
cmdargs-0.9.7 (0.10)
comonad-3.0.0.2
contravariant-0.2.0.2
mtl-2.0.1.0 (2.1.2)
cairo-0.12.3.1
gio-0.12.3
pango-0.12.3
gtk-0.12.3.1
semigroupoids-3.0
void-0.5.7
MemoTrie-0.5
vector-space-0.8.2
active-0.1.0.2
vector-space-points-0.1.1.1
diagrams-core-0.5.0.1
diagrams-lib-0.5.0.1
diagrams-cairo-0.5.1 (0.5.0.2)

We can immediately see that there are newer versions of the split, transformers, cmdargs, and mtl packages (and precisely what those newer versions are). We can also see that the version of diagrams-cairo to be installed is newer than the version on Hackage (since this is a development version). These aren’t necessarily problems in and of themselves, but in my experience, if you don’t know why cabal or cabal-dev have chosen outdated versions of some packages, it’s probably worth investigating. (--dry-run -v3 can help here.) This is also useful when uploading new versions of packages, to make sure they work with the latest and greatest stuff on Hackage. In this case the problems are just because of some changes I made to the .cabal file for the purposes of this blog post, making some upper bounds too restrictive, but in general it could be due to other dependencies as well.

About these ads
This entry was posted in haskell and tagged , , , , , . Bookmark the permalink.

7 Responses to Identifying outdated packages in cabal install plans

  1. Mikhail Glushenkov says:

    Inspired by your post, I wrote a patch that adds this functionality to cabal-install itself:
    https://github.com/haskell/cabal/pull/1014
    No highlighting yet, since I didn’t want to add a dependency on ansi-terminal.

  2. Sönke Hahn says:

    Are you aware of packdeps?
    (http://hackage.haskell.org/package/packdeps)

    • Brent says:

      Yes, and I am subscribed to get alerts about new dependencies for all my packages. I view packdeps and highlight-versions as complementary tools. I probably should have mentioned packdeps in my blog post!

  3. dmbarbour says:

    Is there a way to view dependencies that have already been installed?

    • Brent says:

      You mean to highlight packages which are already installed? Or do you mean to have cabal show you all the dependencies of a particular package, including those which are installed as well as those which aren’t? The first is certainly possible but would be more than just a few minutes of work to add, because so far I have only used the hackage-db package, which gives access to info about packages on Hackage but not actually about what is installed. For that you would have to use the Cabal library directly. I don’t plan to add that feature, but patches welcome. The second must be possible as well, but not with highlight-versions directly; it would have to be a change in cabal-install, or a separate tool using the Cabal API.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s