Cabal build and cabal test should install their own dependencies

[bitemyapp]

cabal install --dependencies-only and cabal install --dependencies-only --enable-tests

Users don't know or care about a (stateful) plan maintained via configure or otherwise. They have declarative commands that they want to work the first time.

[tibbe]

I 100% agree. The plan is to automatically install dependencies at least when sandboxes are used (as that's always safe), but no one has had time to work on it yet.

[23Skidoo]

Two issues that bother me a little bit:

1. Running the solver on each cabal build will slow down the build times.
2. Too much magic is not always a good thing, since it makes it harder to see what's going on. I also like being in control, e.g. sometimes it's useful to check the output of cabal install --dry-run before installing.

I suggest that we should only try installing dependencies when configure fails, and ask the user first (maybe skip this prompt in the sandbox case). Example:

$ cabal test
Resolving dependencies...
Configuring cabal-install-1.21.1.0...
cabal: At least the following dependencies are missing:
HUnit -any,
QuickCheck >=2.5 && <2.8,
extensible-exceptions -any,
regex-posix -any,
test-framework -any,
test-framework-hunit -any,
test-framework-quickcheck2 >=0.3
Do you want to install the missing dependencies automatically? [Y/N] y
[Runs `cabal install --only-dep` followed by `cabal test`]

[bitemyapp]

You don't need to run the solver on each cabal build.

I don't see it as "too much magic". When I write Clojure, I can run lein test and it will just do the right thing and do everything that needs to be done to run the tests, including install dependencies. If a sandbox exists, Cabal should do the same.

Prompts are problematic for scripting.

[23Skidoo]

Prompts are problematic for scripting.

This can be solved with an -y parameter.

[bitemyapp]

It's annoying for scripting and live users. It's one of my least favorite things about apt-get. Leiningen has never needed it. I'd rather not repeat mistakes made by other projects.

[tibbe]

I think we should just do the right thing and have an escape hatch for people who want it (e.g. --no-install-deps or some sort.) The current cabal is way to stateful, probably a leftover from some configure/make legacy. Modern build systems don't work this way and for good reasons: a stateful model is harder to work with and makes reproducible builds much harder (because the command line invocation no longer captures the whole set of configuration.)

[23Skidoo]

It's one of my least favorite things about apt-get. Leiningen has never needed it. I'd rather not repeat mistakes made by other projects.

'-y'/'--non-interactive' can be also made a config file parameter, so it will be less annoying.

[23Skidoo]

It's one of my least favorite things about apt-get.

BTW, apt-get lets you disable prompts in the config file: http://superuser.com/questions/164553/automatically-answer-yes-when-using-apt-get-install

[fujimura]

+1 for avoid prompts here. Even besides prompts are good or bad, making non-interactive command(in this case, cabal test) into interactive one will be very confusing for existing users.

[rrnewton]

+1 for all steps towards a less stateful model. The stateful nature of the thing has caused so much pain. Especially when using it in complex configurations and by scripts rather than with careful manual interaction.

[ghost]

Another +1 for avoiding prompts and just doing the right thing by default. Better to optimize for the general case where typical users want things to just work smoothly with minimal intervention. Power users that really need to see every step and have greater control should be the ones using custom flags, not the other way around.

[danielcompton]

BTW, apt-get lets you disable prompts in the config file:

What percentage of apt-get users even know that this is available? For that matter, what percentage of apt-get users know that -y exists? Good defaults really do matter.

[bitemyapp]

@danielcompton not only that, but it's incredibly error prone with yum, yum will haphazardly ignore -y flags and you'll be forced to use tools to fake interaction.

apt-get is more reliable about obeying -y, but again, a lot of people don't know it exists.

[ezyang]

Closing this as subsumed by nix-local-build, and even more subsumed by per-component configure #3662.

There's a ticket for per-component install plan solving #1575, but I don't think that's what's being asked for here.