Incorrect error messages for non-existing dependencies

[guest]

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

[kosmikus]

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.

[guest]

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.

[kosmikus]

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.

[guest]

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.