Agreeing on a UI for sandboxes

[Mikhail Glushenkov]

Hi,

On Wed, Aug 29, 2012 at 1:45 AM, Johan Tibell <johan.tibell at gmail.com> 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).

>> 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'?

-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments