Agreeing on a UI for sandboxes

[Johan Tibell]

Hi,

On Fri, Aug 31, 2012 at 5:34 AM, Mikhail Glushenkov
<the.dead.shall.rise at gmail.com> wrote:
> 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).

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