This page contains various notes pertaining to the  "Sandboxed Builds and Isolated Environments" GSoC 2012 project.

The project can be summarised as "merge  cabal-dev into cabal, add selected features from  virthualenv, and polish the result". Specifically, we want to be able to choose a compiler version to be used in the sandbox, and run a shell with a sandbox-restricted compiler and tools. Another important concern is portability: all features must be available on both Windows and *nix. One feature that is not going to be supported is cabal-dev ghci (depends on cabal repl patches which are not yet merged). Additionally, compilers other than GHC aren't going to be supported, at least initially.

Mechanisms described on the PackageEnvironments page form a starting point for the implementation of the internal part; ideas from  Johan Tibell's "Cabal of my dreams" post influence the command-line UI design.

Implementation plan

Because of the difficulties of merging large and invasive changes into mainline Cabal I intend to structure my work as several smaller patch sets which can be merged one-by-one, preferably during the summer period. It is also important to minimise the impact on the rest of the Cabal library initially, even if that means some code duplication. Once a working version of the code has been merged, it will be much easier to build up on that and apply refactoring & polishing changes.

At this moment, I plan to break up the project into the following stages:

Extend the package index format

Implement the extended package index format as described in the  PackageEnvironments. This is the foundation that the later stages build on.

Q: Do we need the cabal index subcommand?

A: It can be useful for debugging, but should probably be hidden from users.

Implement a cabal sandbox subcommand

This is the "merge  cabal-dev into cabal" part. The idea is to make cabal-dev available as a cabal subcommand. The implementation will use the extended package index and package environment file, and the UI will be modeled after cabal-dev, but with some differences:

• cabal sandbox build will run configure and add all dependencies to the sandbox automatically, so there will be no need for cabal sandbox install and cabal sandbox configure. Ditto for cabal sandbox bench and cabal sandbox test.
• In addition to add-source, there will be a link-source subcommand for working on multiple packages simultaneously. Q: Can we make link-source the default?
• It will be possible to specify the compiler version to be used in the sandbox.

Example session:

$ cabal sandbox init --with-compiler=/path/to/ghc
$ cabal sandbox link-source /path/to/unreleased-package
$ cabal sandbox build
Configuring...
Building dependency-1...
Building dependency-2...
Building unreleased-package...
Building...
$ vim /path/to/unreleased-package/.../SomeModule.hs
$ cabal sandbox build
Building unreleased-package...
Building...

Implement cabal sandbox shell

This feature (inspired by  virthualenv) will allow to run a shell with a sandbox-restricted compiler and tools. Important: Windows support.

Revise the UI and polish

Implementing build, test, bench and others as cabal sandbox subcommands is redundant. These commands should be made aware of whether there is an sandbox active; they should be also changed to run configure and install dependencies automatically.

Example session:

$ cabal sandbox init
$ cabal build
Note: building in a sandbox.
Building dependency-1...
Building dependency-2...
Building...

We can also remove the cabal sandbox subcommand completely and make cabal build initialise a sandbox implicitly when there is none; this will give us  hermetic builds.  Philipp Schuster's project, if successful, will make this option more practical.

Progress

Week 1

• Wrote this document
• Started working on extending the index format
• ...

Miscellaneous

To look at: the Setup.hs dependencies issue that Rogan talks about  here.