[RFC] Improve 'Could not resolve dependencies' error messages

[chshersh]

Cabal is unfortunately infamous for its hard-to-decode error message when it can't find the build plan for the package. Experienced cabal-install users can decode them but even for them, it takes some time.

Here is one example:

$ cabal build
Resolving dependencies...
cabal: Could not resolve dependencies:
[__0] trying: colourista-0.1.0.1 (user goal)
[__1] trying: base-4.16.3.0/installed-4.16.3.0 (dependency of colourista)
[__2] trying: sauron-0.0.0.0 (user goal)
[__3] next goal: time (dependency of sauron)
[__3] rejecting: time-1.11.1.1/installed-1.11.1.1 (conflict: sauron =>
time^>=1.7)
[__3] skipping: time-1.12.2, time-1.12.1, time-1.12, time-1.11.1.2,
time-1.11.1.1, time-1.11.1, time-1.11, time-1.10, time-1.9.3, time-1.9.2,
time-1.9.1, time-1.9, time-1.8.0.4, time-1.8.0.3, time-1.8.0.2, time-1.8.0.1,
time-1.8 (has the same characteristics that caused the previous version to
fail: excluded by constraint '^>=1.7' from 'sauron')
[__3] rejecting: time-1.7.0.1 (conflict: base==4.16.3.0/installed-4.16.3.0,
time => base>=4.7 && <4.13)
[__3] skipping: time-1.7, time-1.6.0.1, time-1.6, time-1.5.0.1 (has the same
characteristics that caused the previous version to fail: excludes 'base'
version 4.16.3.0)
[__3] rejecting: time-1.5 (conflict: sauron => time^>=1.7)
[__3] skipping: time-1.4.2, time-1.4.1, time-1.4.0.2, time-1.4.0.1, time-1.4,
time-1.3, time-1.2.0.5, time-1.2.0.4, time-1.2.0.3, time-1.2.0.2,
time-1.2.0.1, time-1.2, time-1.1.4, time-1.1.3, time-1.1.2.4, time-1.1.2.3,
time-1.1.2.2, time-1.1.2.1, time-1.1.2.0, time-1.0, time-1.13 (has the same
characteristics that caused the previous version to fail: excluded by
constraint '^>=1.7' from 'sauron')
[__3] fail (backjumping, conflict set: base, sauron, time)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: time, sauron, base, colourista
Try running with --minimize-conflict-set to improve the error message.

It's not really clear what's wrong here immediately.

I propose an alternative, a friendlier and probably clear output formatting:

abal: [build-plan-error]
    Couldn't find a valid build plan that satisfies constraints for all packages

Build plan details:

❌ sauron-0.0.0.0
├── ✅ base-4.16.3.0 (GHC 9.2.4)
├── ✅ colourista-0.1.0.1
└── ❌ time  <==  Problems satisfying this dependency
    ├── ❌ time-1.11.1.1 (boot version)
    │    └── sauron  ==>  time ^>= 1.7  (incompatible bounds)
    │
    ├── ❌ time-1.7.0.1
    │   └── time  ==>  base >= 4.7 && < 4.13 (conflicts with: base-4.16.3.0)
    │
    └── ❌ time (skipping 32 other versions)
         └── sauron  ==>  time ^>= 1.7  (incompatible bounds)

Suggestions to fix the problem:

  * Edit bounds for your dependencies
  * Try running with '--minimize-conflict-set' to improve the error message

---

This issue is created as a followup from one of the old issues:

• Provide more user friendly error messages when no valid build plan is found #2858 (comment)

I'm creating this issue to track this feature request and discuss potential improvements. But currently, I don't have the capacity to implement this feature and push it through.

[Mikolaj]

That looks great. Would --minimize-conflict-set generate a, possibly more accurate but taking more time to compute, message in the new style? Or would it display the old style message? (If not, how does a power user get the old look back?) In either case, we should change the description of --minimize-conflict-set.

Edit: actually, the description is acceptable if it just tweaks the solver, as it always did.

[grayjay]

@chshersh Thanks for opening a new issue! What is the meaning of the tree structure? I initially thought that it showed the dependency relationships printed in the original cabal output, but then base would be under colourista instead of sauron.

@Mikolaj --minimize-conflict-set reruns the solver with subsets of the four conflicting packages (time, sauron, base, and colourista), to see whether any of them contains a conflict, which would be simpler than the original conflict.

[Mikolaj]

@grayjay: thank you for the explanation, which helps me understand what's going on, so perhaps it's worth adding to the docs (not necessarily in the same PR as the tree visualization one).

I see the comments in the RFC are mostly expressions of unconditional support (14 as of now), so let's not allow it to bitrot. @chshersh, could you elaborate on the semantics of the ASCII picture? Ideally in a form that might eventually end up in the docs.