Agreeing on a UI for sandboxes

[Johan Tibell]

Hi,

On Sat, Sep 1, 2012 at 3:11 AM, Mikhail Glushenkov
<the.dead.shall.rise at gmail.com> wrote:
> On Fri, Aug 31, 2012 at 11:43 PM, Johan Tibell <johan.tibell at gmail.com> wrote:
>>
>> Why does `cabal install` affect the saved configure flags? Does it do
>> that today even if you don't use the new sandbox stuff?
>
> It doesn't have to affect the package environment file, but otherwise
> you'll need to specify the configure flags twice:
>
> $ cabal sandbox-init
> $ cabal install --only-dependencies -w /path/to/compiler
> $ cabal configure -w /path/to/compiler # Fails without -w

I see. This is no worse (or better) than the current situation today.
I think the real solution here is to get rid of a separate "install
the obviously needed dependencies"-step. Since I think we need to
discuss such a change more in depth, I suggest we just leave the
sandboxes having to repeat the -w flag twice, just like non-sandboxes
already have to.

In general lets just have sandboxes behave exactly as non-sandbox
builds, with the exception of the separate package DB and rebuilding
add-source deps, for now. This will get something useful into users'
hands quicker.

>> That's fine I think. It's like you added a dependency of the main
>> library. The user will need to install that dependency by running
>>
>>    cabal install --only-dependencies
>>
>> There's a question whether he/she would have to run that in the dir of
>> the dependency or the dir of the main lib.
>
> The simple implementation is to make 'cabal build' imply 'cabal
> install' for all add-source dependencies. This will download and
> install all newly-added dependencies.

Andres might protest that this again would imply installing stuff from
the Internet. Lets have it instead imply `configure && cabal build`
and registering in the sandbox package DB for now. We'll revisit
automatic installation later.

-- Johan