Better error output in case of flags WAS Version bounds in cabal file revisions not taken into account?

[bergmark]

I upgraded to the latest version of all my dependencies (not using a snapshot), after this it seems like stack doesn't find a build-plan for blaze-builder-enumerator, relevant snippet:

--  Failure when adding dependencies:
      blaze-builder: needed (>=0.2.1.4 && <0.4), latest is 0.4.0.1, but 0.4.0.1 found
    needed for package: blaze-builder-enumerator-0.2.1.0

But looking at the revision history the package should allow blaze-builder 0.4.*. I don't run across this problem if using a freeze file with cabal-install

This should be reproducible by running stack install on https://github.com/bergmark/stack-bbe-reproduction

Full log (also tested on Version 0.1.2.7, Git revision 68e194622b3c52be3d386b2e9b807ec1ac288828):

> stack install --dry-run -v
Version 0.1.2.1, Git revision 2723b3567e44725b176c35786a5e11db454d183e
2015-08-04 08:52:47.349544: [debug] Checking for project config at: /Users/adam/repos/trustee/bbe/stack.yaml @(stack-0.1.2.1:Stack.Config src/Stack/Config.hs:446:9)
2015-08-04 08:52:47.349875: [debug] Loading project config file stack.yaml @(stack-0.1.2.1:Stack.Config src/Stack/Config.hs:469:13)
2015-08-04 08:52:47.351563: [debug] Run process: ghc --info @(stack-0.1.2.1:System.Process.Read src/System/Process/Read.hs:255:3)
2015-08-04 08:52:47.411485: [debug] Run process: ghc --numeric-version @(stack-0.1.2.1:System.Process.Read src/System/Process/Read.hs:255:3)
2015-08-04 08:52:47.443212: [debug] Run process: ghc-pkg --no-user-package-db field --simple-output Cabal id @(stack-0.1.2.1:System.Process.Read src/System/Process/Read.hs:255:3)
2015-08-04 08:52:47.470321: [debug] Run process: ghc-pkg --no-user-package-db list --global @(stack-0.1.2.1:System.Process.Read src/System/Process/Read.hs:255:3)
2015-08-04 08:52:47.822214: [debug] Run process: ghc-pkg --global --no-user-package-db dump --expand-pkgroot @(stack-0.1.2.1:System.Process.Read src/System/Process/Read.hs:255:3)
2015-08-04 08:52:47.854254: [debug] Run process: ghc-pkg --user --no-user-package-db --package-db /Users/adam/.stack/snapshots/x86_64-osx/ghc-7.8/7.8.4/pkgdb/ dump --expand-pkgroot @(stack-0.1.2.1:System.Process.Read src/System/Process/Read.hs:255:3)
2015-08-04 08:52:47.871442: [debug] Run process: ghc-pkg --user --no-user-package-db --package-db /Users/adam/repos/trustee/bbe/.stack-work/install/x86_64-osx/ghc-7.8/7.8.4/pkgdb/ dump --expand-pkgroot @(stack-0.1.2.1:System.Process.Read src/System/Process/Read.hs:255:3)
While constructing the BuildPlan the following exceptions were encountered:

--  Failure when adding dependencies:
      snap-core: needed (-any), latest is 0.9.7.2, but couldn't resolve its dependencies
      snap-server: needed (-any), latest is 0.9.5.1, but couldn't resolve its dependencies
    needed for package: bbe-0.1.0.0

--  Failure when adding dependencies:
      blaze-builder: needed (>=0.2.1.4 && <0.4), latest is 0.4.0.1, but 0.4.0.1 found
    needed for package: blaze-builder-enumerator-0.2.1.0

--  Failure when adding dependencies:
      blaze-builder-enumerator: needed (>=0.2 && <0.3), latest is 0.2.1.0, but couldn't resolve its dependencies
    needed for package: snap-core-0.9.7.2

--  Failure when adding dependencies:
      blaze-builder-enumerator: needed (>=0.2.0 && <0.3), latest is 0.2.1.0, but couldn't resolve its dependencies
      snap-core: needed (>=0.9.3 && <0.10), latest is 0.9.7.2, but couldn't resolve its dependencies
    needed for package: snap-server-0.9.5.1

[bergmark]

I figured it out. the newbuilder flag on blaze-builder-enumerator was set to false, that's where the < 0.4 constraint came from, so this isn't a bug but it took me a while to figure it out.

The error message could be more helpful I think, here it prints 4 failures, the 2nd item is the leaf so it's the one that needs to be fixed. It would be nice if that item was "highlighted" somehow. It'd also be useful if the flags were printed since I didn't notice that newbuilder was set to the wrong value.

[snoyberg]

Interested in taking a stab at improving this? If the flag selection was kept short, hopefully it wouldn't overwhelm the output. I'd also be in favor of simply collapsing all of the "couldn't resolve its dependencies" into a much shorter message so that the real offenders get prominence.

[snoyberg]

Bump

[sjakobi]

As a first step I have added the flag information (v0):

While constructing the BuildPlan the following exceptions were encountered:

--  Failure when adding dependencies:    
      snap-core: needed (-any), couldn't resolve its dependencies
      snap-server: needed (-any), couldn't resolve its dependencies
    needed for package bbe-0.1.0.0

--  Failure when adding dependencies:    
      blaze-builder: needed (>=0.2.1.4 && <0.4), 0.4.0.1 found (latest applicable is 0.3.3.4)
    needed for package blaze-builder-enumerator-0.2.1.0 with flags:
      newbuilder: False

--  Failure when adding dependencies:    
      blaze-builder-enumerator: needed (>=0.2 && <0.3), couldn't resolve its dependencies
    needed for package snap-core-0.9.7.2

--  Failure when adding dependencies:    
      blaze-builder-enumerator: needed (>=0.2.0 && <0.3), couldn't resolve its dependencies
      snap-core: needed (>=0.9.3 && <0.10), couldn't resolve its dependencies
    needed for package snap-server-0.9.5.1

Now to restructuring the output. What do you think about something like this (v1):

While constructing the build plan the following exceptions were encountered:

Impossible version constraints:

  blaze-builder:
    needed: >=0.2.1.4 && <0.4, found: 0.4.0.1, latest applicable: 0.3.3.4
    for:
      blaze-builder-enumerator-0.2.1.0, needing: >=0.2.1.4 && <0.4, with flags:
        newbuilder: False


Unresolved dependencies:

  snap-core:
    needed: >=0.9.3 && <0.10
    for:
      bbe-0.1.0.0, needing -any
      snap-server, needing >=0.9.3 && <0.10

  snap-server:
    needed: -any
    for:
      bbe-0.1.0.0, needing -any

  blaze-builder-enumerator:
    needed: >=0.2 && <0.3
    for:
      snap-core-0.9.7.2, needing >=0.2 && <0.3

If the unresolved dependencies take too much space in v1, how about something like this (v2):

While constructing the build plan the following exceptions were encountered:

Impossible version constraints:

  blaze-builder:
    needed: >=0.2.1.4 && <0.4, found: 0.4.0.1, latest applicable: 0.3.3.4
    for:
      blaze-builder-enumerator-0.2.1.0, needing: >=0.2.1.4 && <0.4, with flags:
        newbuilder: False


Unresolved dependencies:
  snap-core:
    needed: >=0.9.3 && <0.10
    for: bbe-0.1.0.0, snap-server
  snap-server:
    needed: -any
    for: bbe-0.1.0.0
  blaze-builder-enumerator:
    needed: >=0.2 && <0.3
    for: snap-core-0.9.7.2

Thoughts?

Also: Are these messages too terse? Do they need more human-language?

[borsboom]

It always takes me a while to figure what these messages are actually trying to tell me (what exactly does "needed" vs. "latest applicable" mean?), so I think more human language would be helpful. On the other hand, sometimes you get pages of cascading error messages, most of which aren't actually very useful for finding the root cause, and more verbosity could make that problem even worse. I wonder if it would be possible for this to suppress the redundant cascading error messages (at least by default). I think between those two changes, it would be way easier to interpret.

[sjakobi]

It always takes me a while to figure what these messages are actually trying to tell me (what exactly does "needed" vs. "latest applicable" mean?), so I think more human language would be helpful.

I'll try to make the message easier to understand.

On the other hand, sometimes you get pages of cascading error messages

I'll try to construct a case like that. But I'm wondering whether we shouldn't try to collect some example projects as a supply for work on the solver, the error messages etc.
@bergmark's https://github.com/bergmark/stack-bbe-reproduction could be a start.
Maybe we could put them into a folder pathological-projects? :) Or should this be a separate repository?

I wonder if it would be possible for this to suppress the redundant cascading error messages (at least by default).

I'll try this as soon as I have a good example case.

[sjakobi]

Can we resolve this issue with #1791 and centralize the discussion of the error message improvements in #1739?

[mgsloan]

Yup, sounds good to me