cabal sandbox tips

In case you missed it, starting from version 1.18 cabal-install has awesome sandboxing capabilities. Here I share a couple of tricks that will make your sandboxing experience even better.

Location-independent sandboxes

By default, cabal uses sandbox only in the directory where cabal.sandbox.config is present. This is inconvenient when sharing a sandbox among multiple projects, and in general makes it somewhat fragile.

With cabal 1.19 (i.e. cabal HEAD as of now) you can set the CABAL_SANDBOX_CONFIG environment variable to the path to your cabal.sandbox.config, and the corresponding sandbox will be used regardless of your current directory.

I’ve defined convenience functions for myself such as

tasty() {
  export CABAL_SANDBOX_CONFIG=$HOME/prog/tasty/sandbox/cabal.sandbox.config
  sandbox_name=tasty
}

for every sandbox I commonly use.

Notice how I also set the sandbox_name variable to the human-readable name of the sandbox. It can be displayed in the prompt as follows:

setopt prompt_subst # force prompt re-evaluation
PROMPT='${sandbox_name+[sandbox: $sandbox_name] }%~ %% '

(sandbox name in the prompt idea is due to /u/cameleon)

Sandbox-aware ghc

Sandboxes only affect cabal, but not ghc or ghci when those are invoked directly. At some point in the future we’ll be able to write

% cabal exec ghc ...

For now I’ve defined the following sandbox-aware wrappers for ghc and ghci:

Clone the repo somewhere

% git clone https://gist.github.com/9365969.git ghc_sandbox

and include in your .bashrc or .zshrc

. ~/path/to/ghc_sandbox/ghc_sandbox.sh

(Why am I wrapping ghci instead of using cabal repl? cabal repl has some side-effects, like re-installing packages, that are not always desirable. And ghci is much faster to start, too.)