Agreeing on a UI for sandboxes
johan.tibell at gmail.com
Fri Aug 31 23:43:58 CEST 2012
On Fri, Aug 31, 2012 at 12:27 PM, Mikhail Glushenkov
<the.dead.shall.rise at gmail.com> wrote:
> On Fri, Aug 31, 2012 at 8:25 PM, Johan Tibell <johan.tibell at gmail.com> wrote:
>> 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.
> It'll still be a bit confusing:
> $ cabal sandbox-init
> $ cabal install --only-dependencies -w /path/to/compiler
> $ cabal configure # Uses configure flags given to install
Why does `cabal install` affect the saved configure flags? Does it do
that today even if you don't use the new sandbox stuff?
>> 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?).
> This is very easy to implement, but all packages depending on the
> reinstalled libraries will have to be relinked and reinstalled, which
> is not very fun. You can test this by running 'cabal-dev install
> Cabal/ cabal-install/' twice in the Cabal source dir. With a larger
> number of dependencies it'll be even more annoying.
Lets try to make it work first and then optimize it. If we don't make
it work all that will mean is that the user will have to perform the
steps manually (i.e. 'cd' to the dependency directory, run build, 'cd'
to the main directory, run install).
More information about the cabal-devel