Performing consistent builds is critical in software development, but the current system in GHC/Haskell of per-user and per-system GHC package databases interferes with this need for consistency. It is difficult to precisely identify the dependencies of a given project, and changes necessary to enable one project to build may render another project inoperable. If each project had a separate package database, each project could be built in a sandbox.
Galois has released cabal-dev: a tool for managing development builds of Haskell projects within sandboxes.
Both cabal-install repositories and sandboxed ghc package databases are used to prevent interactions between disparate projects, or user package databases. cabal-dev is similar to capri, which was coincidentally developed concurrently. The two projects take slightly different approaches to sandboxing, and exhibit slightly different behaviors depending on the state of the global package database, and the versions of the tools installed.
For most packages, just use cabal-dev instead of cabal, and you will get a sandboxed build that will not install anything (even automatically installed dependencies) into the user or global ghc package databases. If your build depends on patched or unreleased libraries, you can add them to your sandboxed build environment so they can be installed by cabal-dev or cabal by running:
> cabal-dev add-source /path/to/source/code
Where /path/to/source/code is either a path to a source directory containing a .cabal file, or an sdist tarball.Cabal-dev has been in use at Galois for roughly six months now, but it should currently be treated as alpha software: we’ve exercised a few execution paths heavily, but it still has a number of rough edges.Cabal-dev is hosted on hackage and git-hub. A brief tutorial can be found in the README.md.