Sandboxed Builds and Isolated Environments

Imported from Trac wiki; be wary of outdated information or markup mishaps.

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

The project can be summarised as "integrate cabal-dev into cabal 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 are not 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.

Current status

The infrastructure changes and the preliminary UI patches have been already merged, we need to agree on and implement the final UI. The --package-root option is not yet implemented, and shared sandboxes should be tested a bit more. We decided not to implement cabal sandbox-shell for now.

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 (DONE)

Implement the extended package index format as described in Package Environments#extended-source-package-index-format. 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 be hidden from users.

Implement a cabal sandbox subcommand (DONE)

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 add all dependencies to the sandbox automatically, so there will be no need for cabal sandbox install. Ditto for cabal sandbox bench and cabal sandbox test.
• In addition to add-source, there will be a link-source subcommand that will rebuild and re-add the linked package each time it changes. 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-configure
Configuring...
$ cabal sandbox-build
Building dependency-1...
Building dependency-2...
Building unreleased-package...
Building...
$ vim /path/to/unreleased-package/.../SomeModule.hs
$ cabal sandbox-build
Building unreleased-package...
Building...

Revise the UI (DONE)

The cabal sandbox init subcommand will be replaced by a --sandbox flag to --configure; --link-source will be also made a --configure option. The configure, build, test, bench and install commands will be made aware of whether there is an sandbox active.

Example session:

$ cabal configure --sandbox --with-compiler=/path/to/ghc --link-source=/path/to/dependency-1
$ cabal build
Note: building in a sandbox.
Building dependency-1...
Building dependency-2...
Building...

Once ghc-pkg gets Nix-style package management, the --sandbox switch will be made the default.

Implement a --package-root configure option (TODO)

For large sets of dependencies, linking sources manually with --link-source is tedious. It would be nice if configure could be just given a path to the package directory, and then would walk the directory tree and discover the .cabal files automatically

Q: Given --package-root, --link-source is redundant. Should it be removed?

Allow linking to VCS repositories from sandboxes (TODO)

It would be nice to allow linking to Git/Darcs/... repositories from sandboxes. cabal build would then update cached working copies automatically.

Implement shared sandboxes (DONE)

Allow providing an optional path argument to configure --sandbox so that sandboxes could be shared.

Implement cabal sandbox shell (POSTPONED)

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

Miscellaneous

Bugs/known issues/things to look at:

• The Setup.hs dependencies issue that Rogan talks about here.
• The wxdirect issue apfelmus mentions here.
• Interesting test cases: yi, xmonad (requires patches to xmonad/dyre to work with sandboxes)
• cabal configure --sandbox should imply cabal add-source . (?)
• cabal-meta's functionality without sandboxing.