Re: Agreeing on a UI for sandboxes

Hi, On Fri, Aug 31, 2012 at 5:34 AM, Mikhail Glushenkov wrote:

Hi,

On Wed, Aug 29, 2012 at 1:45 AM, Johan Tibell wrote:

...

Perhaps a separate command, cabal init-sandbox, would be the best approach. Running that command would create the right package environment for running in a sandbox and the remaining commands would then use that sandbox. Separating init-sandbox from configure prevents the user from removing the sandbox preference when reconfiguring for some other reason (e.g. to add --enable-tests). To get out of the sandbox the user would edit the package environment file.

One problem with a separate sandbox-init command is that it gives you two ways to specify configure flags. E.g. you can do

$ cabal sandbox-init -w /path/to/compiler-1 $ cabal install --only-dependencies

and then run

$ cabal configure -w /path/to/compiler-2

which will rewrite the package environment file, but then fail due to dependencies not being installed (since we are now using a different compiler). It can also be a bit non-obvious that when you run 'configure' after 'sandbox-init' it uses the configure flags given to 'sandbox-init' earlier (saved in the package environment file).

Let's have sandbox-init not take any configure arguments. It should just mark that the current repo should use a sandbox until sandbox-delete is run.

...

...

I wouldn't change it yet. If at all, it should be a flag per add-source. Not everything you add-source are libraries you necessarily actively develop at the time. And I guess you can add-source not only local packages, right?

I'm worried about making cabal even more cumbersome to use. [...] If the use manually has to rebuild dependencies every time the change even when using a sandbox we have essentially no improvement over status quo and or cabal-dev.

We can make automatic updating of dependencies the default and current behaviour optional. In any case, we need to agree how to update dependencies automatically. A naive algorithm is to just reinstall everything (which is what cabal-dev does). We can try to be a bit smarter and do something like the following:

For each dependency added with add-source: If the dependency has already been configured and there is no need to reconfigure: Either just run 'cabal build' and reinstall only if the produced lib/exe is newer than the one we have installed, or get a list of all source files for each target (is this possible?) and rebuild&reinstall only if there is some source file newer than the installed target. Otherwise just configure, build and install.

Also, should this happen each time the user runs 'cabal build' or only when running 'cabal install'?

Here's an idea: as a compromise we can have cabal build imply reb-building and installing only add-source dependencies. This means nothing has to be downloaded from the internet. Lets not worry about minimize rebuilding now. Just call build in each add-source repo and reinstall the library. GHC will already skip most of the rebuilding (but not the relinking?). -- Johan