Changes between Version 3 and Version 4 of SandboxedBuildsAndIsolatedEnvironments

Timestamp:

06/12/12 17:02:14 (11 months ago)

Author:

refold

Comment:

update

SandboxedBuildsAndIsolatedEnvironments

@@ -2 +2 @@
 This page contains various notes pertaining to the [http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/refold/41002 ""Sandboxed Builds and Isolated Environments""] GSoC 2012 project.
 
-The project can be summarised as "merge [http://hackage.haskell.org/package/cabal-dev cabal-dev] into cabal, add selected features from [http://hackage.haskell.org/package/virthualenv 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.
+The project can be summarised as "integrate [http://hackage.haskell.org/package/cabal-dev 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 [http://blog.johantibell.com/2012/03/cabal-of-my-dreams.html Johan Tibell's "Cabal of my dreams" post] influence the command-line UI design.
@@ -18 +18 @@
 Q: Do we need the `cabal index` subcommand?
 
-A: It can be useful for debugging, but should probably be hidden from users.
+A: It can be useful for debugging, but should be hidden from users.
 
 == Implement a `cabal sandbox` subcommand ==
@@ -24 +24 @@
 This is the "merge [http://hackage.haskell.org/package/cabal-dev 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?
+    * `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.
 
@@ -31 +31 @@
 
 {{{
-$ cabal sandbox init --with-compiler=/path/to/ghc
-$ cabal sandbox link-source /path/to/unreleased-package
-$ cabal sandbox build
+$ 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...
@@ -40 +41 @@
 Building...
 $ vim /path/to/unreleased-package/.../SomeModule.hs
-$ cabal sandbox build
+$ cabal sandbox-build
 Building unreleased-package...
 Building...
 }}}
 
-== Implement `cabal sandbox shell` ==
+== Revise the UI and add polish ==
 
-This feature (inspired by [http://hackage.haskell.org/package/virthualenv 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. The top-level versions of 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.
+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; they will be also changed to install dependencies automatically.
 
 Example session:
 
 {{{
-$ cabal sandbox init
+$ cabal configure --sandbox --with-compiler=/path/to/ghc --link-source=/path/to/dependency-1
 $ cabal build
 Note: building in a sandbox.
@@ -64 +61 @@
 }}}
 
-We can also remove the `cabal sandbox` command completely and make `cabal build` initialise a sandbox implicitly when there is none; this will give us [http://blog.johantibell.com/2012/03/cabal-of-my-dreams.html hermetic builds]. [http://www.google-melange.com/gsoc/project/google/gsoc2012/phischu/19001 Philipp Schuster's project], if successful, will make this option more practical. 
+Once `ghc-pkg` gets Nix-style package management, the `--sandbox` switch will be made the default.
+
+== Implement a `--package-root` configure option ==
+
+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. Another nice feature is linking to Git/Darcs/... repositories.
+
+Q: Given `--package-root`, `--link-source` is redundant. Should it be removed?
+
+== Implement shared sandboxes ==
+
+Allow providing an optional path argument to `configure --sandbox` so that sandboxes could be shared.
+
+== Implement `cabal sandbox shell` ==
+
+This feature (inspired by [http://hackage.haskell.org/package/virthualenv virthualenv]) will allow to run a shell with a sandbox-restricted compiler and tools. Important: Windows support.
 
 = Progress =
@@ -72 +83 @@
   * Wrote this document
   * Started working on extending the index format
-  * ...
 
 = Miscellaneous =