| | 92 | cabal-dev |
| | 93 | |
| | 94 | cabal-dev provides what it calls a sandbox for source packages and installed packages. `cabal-dev` has a command line interface that is very similar to that of `cabal`, so that it can be used as a drop-in replacement. It is implemented as a wrapper around the cabal-install command. |
| | 95 | |
| | 96 | For source packages, the sandboxing mean providing a local source package set that overrides the global package index. Tarballs can be added to this index. It provides a command `cabal-dev add-source /path/to/source/code` which generate an `sdist` snapshot of the given package and adds that tarball to the local source index. |
| | 97 | |
| | 98 | For installed packages, the sandboxing means that packages are not registered into the user or global ghc package database. |
| | 99 | |
| | 100 | The user interface provides two ways to install a package into a sandbox, either to add the source package into the sandbox, or to install a package into the sandbox. In the latter case the source is not available if something needed to be rebuilt (e.g. needed profiling version later). |
| | 101 | |
| | 102 | Note that when source packages are added to the sandbox, it is a snapshot of the package, not a live link to another build tree. This is probably not by design, but a limitation of cabal that cabal-dev cannot easily fix. |
| | 103 | |
| | 104 | TODO: what is the default install location for cabal-dev? If it sets the --prefix to be a local directory does that mean it only works with packages that are prefix independent? |
| | 105 | |
| | 106 | TODO: when you do `cabal-dev add-source` to add a source package to the sandbox, does that just make that version available, or does it mask all other versions of that package? More generally, the question is does cabal-dev force that `add-source`'d one to be used, or how does it handle selecting the package to use? |
| | 107 | |
