Providing a smooth default user experience

[Bardur Arantsson]

On 10/31/2012 06:22 PM, Johan Tibell wrote:
> Hi all,
> 
> Sensible defaults are important to provide a smooth user experience,
> especially for first-time users. There are a few areas where I think cabal
> could improve its default behavior. In particular, here are a couple of
> changes I would like to make:
> 
> *cabal build should imply cabal install --only-dependencies
> *
[--snip--]
> The reasons I've heard for not having build imply installing dependencies
> is that users might not want packages to be downloaded from the internet,
> unless they explicitly use cabal install. While that's a fair point, I
> think it should be an opt-out rather than an opt-in because:

It might be an option to do what Maven (shudder) does here: Have an
explicit "offline" mode (switchable by config or cmdline option) which
simply blocks any online activity with an error message.

> 
>    - Users will end up have to install the dependencies anyway and there's
>    typical no other options than installing them from Hackage.
>    - Many users use cabal install instead of cabal build, for the reasons
>    given above, making it a moot point.
> 
> Proposal: add a --install-dependencies flag to cabal build that defaults to
> True.

+1.

[--snip--]

> *Sandboxing should be used by default*
> 

+1.

> This follows the "make it correct, then make it fast" principle. Sandboxing
> helps with a certain class of build problems, namely problems due to two
> different builds overwriting each others' dependencies in the shared
> package database. This problem shows up as a dangerously sounding cabal
> warning message, mentioning the --force-reinstalls flag.

That, and you end up with broken packages due to no fault of your own
(using the default mode). That's simply bad from a usability perspective.

> Sandboxing is an imperfect solution to this problem, requiring more
> rebuilding of packages than strictly necessary. A final solution would
> involve something like a Nix-style, append-only package database. The Nix
> solution is being worked on, as part of GSoC, but it's a difficult problem
> and it requires more wide-reaching changes (e.g. to ghc, ghc-pkg, ghci, and
> cabal). Since sandboxing is working today (with a few minor tweaks yet to
> be done) and it can be transparently replaced with a better solution once
> we have one, I think we should enable it by default in 1.18.
> 

(Drools about the prospect of true Nix-style package database -- hope's
to hoping that happens at some point.)

> 
> *We should add a cabal run command*
> 

+1.