Incorrect error messages for non-existing dependencies

[bos]

(Imported from Trac #951, reported by guest on 2012-05-15)

When the build-depends-field contains non-existing packages, cabal-install sometimes does not report that these packages could not be found but complains about other constraints being unsolvable.

The attached cabal-file contains a dependency for a non-existing package called "bogus". This is what I get:

$ cabal install --only-dependencies --dry-run
Resolving dependencies...
cabal: Could not resolve dependencies:
next goal: foo (user goal)
rejecting: foo-1.0 (global constraint requires ==0.1.0.0)
trying: foo-0.1.0.0
trying: heist-0.8.0 (dependency of foo-0.1.0.0)
trying: transformers-0.3.0.0 (dependency of heist-0.8.0)
next goal: mtl (dependency of heist-0.8.0)
rejecting: mtl-2.1.1, 2.1 (conflict: heist => mtl>=2.0 && <2.1)
rejecting: mtl-2.0.1.0, 2.0.0.0 (conflict: transformers==0.3.0.0, mtl =>
transformers==0.2.*)
rejecting: mtl-1.1.1.1, 1.1.1.0, 1.1.0.2, 1.1.0.1, 1.1.0.0, 1.0 (conflict:
heist => mtl>=2.0 && <2.1)

When removing "bogus" from the build-depends, cabal-install is able to come up with a working install plan.

Used versions:

$ cabal --version
cabal-install version 0.14.0
using version 1.14.0 of the Cabal library

[bos]

(Imported comment by @kosmikus on 2012-05-15)

Thanks for the report.

I'm not sure what you would actually expect here. The solver has some freedom in which order to try to resolve the goals. And the problem it reports is the first problem it hits. The presence of the bogus dependency in this case prevents the solver from successfully backtracking. So yes, there's more than one problem in this case, and in general, it's difficult to judge which one's the one you want to hear about.

If you remove the bogus dependency, it will still run into the problem you show above at first, but continue backtracking, and will ultimately find a solution (probably by picking an older version of transformers).

So I agree that this might not be the error message you expect, and I see it as a valid enhancement request. But the error message given isn't "incorrect", and I unfortunately don't see a clear heuristics to apply here.

[bos]

(Imported comment by guest on 2012-05-15)

Thanks for answering!

Sounds complicated. I guess, good error reporting for unsuccessful constraint solving is a big subject in its own right.

BTW: Increased verbosity (-v3) results in a message containing this:

[_39] fail (unknown package: bogus)
[__0] fail (backjumping, conflict set: bogus, foo)

Which is what I would expect from cabal-install without increased verbosity.

[bos]

(Imported comment by @kosmikus on 2012-05-15)

It's really a question about which error message to choose. If you scan up in your log, you will see another "fail (backjumping ..." line before the one you've just shown. Currently, the solver tries backtracking to a limit, and if it fails, it will print the first error it encountered. This is based on the heuristic that usually, the first choices involve the least compromises, and are most likely to point to the actual problem. In this case, it actually points at a real problem (namely "transformers-3" being incompatible with your package), but that's not the main problem you're interested in.

I do have something in mind that might fix this. I am planning to use the backtracking solver to generate several install plans and pick a "best" one according to heuristics. We could do the same for error messages. However, it's less clear to me how to define heuristics for what constitutes the best among several error messages.

[bos]

(Imported comment by guest on 2012-05-15)

What about outputting all fails from the solver? Something that would behave similar to

$ cabal install -v3 | grep fail

If this is too verbose as the default behavior, it might be good as one verbosity level.

[grayjay]

I have an idea for improving the summary in cases like this. We could run the solver once to try to find a solution. Then, if it fails, we could run it again, but have it prefer goals from the first run's top-level conflict set. The solver would use the log from the second run, up to the first error, as the summary.

The errors from the second run could be more relevant, because they are likely to come from the final conflict set, which explains why the whole tree has no solution. In this example, the conflict set is probably {bogus, foo}. So the error message would show the solver trying foo and then bogus.

[grayjay]

See #4139 for another example of a misleading first error message.