cabal sandbox tips
Published on
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.)