Utilities for working with cabal packages and your package database

Latest on Hackage:

This package is not currently in any snapshots. If you're interested in using it, we recommend adding it to Stackage Nightly. Doing so will make builds more reliable, and allow to host generated Haddocks.

BSD3 licensed by Jake Wheat
Package-o-tron is a collection of utilities to help managing cabal
files for your projects, maintaining Makefiles and other build
systems, and also some which help with your package database.

The central code is a function which takes a list of folders, then
parses all the imports in all the haskell source in these folders. It
then creates the dependency information between the different files,
and the dependency on packages information (using ghc-pkg dump)

Currently implemented:

The Makefile in the package-o-tron package gives an example of how to
use package-o-tron to help manage a makefile for haskell projects,
using the Makefilerize command.

You could use a Makefile:

* to quickly develop when you have multiple .cabal projects and don't
want to spend time reinstalling them when you do a rebuild (this can
also be much faster if you use -j and have lots of executables)

* if you have files to compile as part of the development which aren't
in a cabal package, or if you want to integrate with existing
Makefiles, e.g. for mixed haskell/c projects.

See the Makefile and in the repo (link below) for an
example of how this works. This tool is used in the hssqlppp project
Makefile (, see the Makefile and there for another example.


CabalLint will check the following issues in your cabal file:

* missing and superfluous other-modules and build-deps in library,exe
and test sections

* version ranges which exclude the latest versions of a build-dep
(just uses packdeps from hackage)

run it like this:
CabalLint package-o-tron.cabal
No output means everything OK


Run on a set of source folders, and it will show you all the packages
referenced by the source in those folders

Planned utils:

Showpackages: extend to show indirectly depended on packages as well

blessed package set creation: run on some folders to get a package
list. Then it follows the package dependencies to get all the needed
non-system packages. Then it looks in your .cabal and copies out the
tarballs for all these packages. Now you can create a fresh install in
a sandbox or fresh machine without needing an internet connection, or
worrying about if hackage is down, or if the latest set of packages
don't install.

Cabal build testing

Use sandboxing to check the sdists from a .cabal install without error
and if there are tests they run and pass. The sandboxing is used to
check a range of versions of ghc crossed with the lowest and latest
versions of the dependencies listed in the .cabal. Later, maybe this
can be extended to search earlier versions of dependencies to get more
accurate lower bounds.

Package database lint:

check your ghc package database for the following issues:
duplicate packages installed
packages which aren't the latest versions installed
not sure how to automatically help with these situations though

Third party cabal install checker:

run a wrapper around cabal-install ... --dry-run. reports:
any reinstalls (easy since cabal already does this)
any different versions of already installed packages would be
any versions of packages which aren't the latest of those packages
would be installed

Third party cabal file hacker:

when you try to install a lot of packages, and some of them have
version constraints on their dependencies which lead to another
package being installed not at the latest version: this will cabal
unpack the offending packages and alter their constraints to allow all
the latest versions of packages automatically. Not completely safe of
course, but I always end up doing this manually and it is really


Depends on 7 packages:
Used by 1 package:
comments powered byDisqus