Add warnings if compiler version doesn't match snapshot compiler version

[bergus]

I've tried to use the compiler option as documented here to get GHC 8 while still using a long-term-support resolver (the nightlies and ghc-specific ones don't contain the packages).
What followed was a version conflict in pretty much every library (or so it seemed) - #1735 did put it nicely as "version checking going nuts". Being new to Stack, I had no idea what to do, and the output is not particularly helpful.

Steps to reproduce

My stack.yaml currently looks like this:

resolver: lts-6.12
compiler: ghc-8.0

packages:
- build\

extra-deps:

flags: {}
ghc-options:
    "*": -Wall

When I ran stack build, it spewed 1030 lines on the console, "While constructing the BuildPlan the following exceptions were encountered:", "Failure when adding dependencies:" and so on.

Expected

Stack should tell me which library is conflicting. In my case, it appears to be GHC, and it should suggest me to drop the compiler option.

Actual

GHC is mentioned nowhere in the output. Only by trial-and-error I found out that removing the compiler option makes it work again.

Stack version

$ stack --version
Version 1.1.2, Git revision c6dac65e3174dea79df54ce6d56f3e98bc060ecc (3647 commits) x86_64 hpack-0.14.0

[sjakobi]

Thanks for the report!

stack-HEAD has much improved dependency conflict reporting, and I'd be interested in hearing your feedback about it: You can either upgrade with stack upgrade --git or wait a few days until a new release has been cut.

An additional warning for a mismatching compiler version might be a good idea.

I'm under the impression that picking a newer compiler than the one specified in the resolver is pretty much always doomed to fail because the base version that comes with ghc will not fit the upper bounds of core packages like array and containers.

The reverse case, where we're using an older compiler than specified in the resolver, may have better chances of resulting in a successful build.

[bergus]

picking a newer compiler than the one specified in the resolver is pretty much always doomed to fail because of the base version that comes with ghc

Yeah, that's what I figured which led me to try dropping the compiler option :-)

You can either upgrade with stack upgrade --git

Hmpf, looks like I can't. (After experiencing some #2175,) the install fails with

--  While building package prelude-extras-0.4.0.3 using:
      C:\Users\…\AppData\Roaming\stack\setup-exe-cache\x86_64-windows\setup-Simple-Cabal-1.22.5.0-ghc-7.10.3.exe --builddir=.stack-work\dist\2672c1f3 register
    Process exited with code: ExitFailure 1
    Logs have been written to: C:\Users\…\AppData\Local\Temp\stack-upgrade5720\stack\.stack-work\logs\prelude-extras-0.4.0.3.log

    Configuring prelude-extras-0.4.0.3...
    Building prelude-extras-0.4.0.3...
    Preprocessing library prelude-extras-0.4.0.3...
    [1 of 1] Compiling Prelude.Extras   ( src\Prelude\Extras.hs, .stack-work\dist\2672c1f3\build\Prelude\Extras.o )
    In-place registering prelude-extras-0.4.0.3...
    Installing library in
    C:\Users\…\AppData\Roaming\stack\snapshots\1183dd29\lib\x86_64-windows-ghc-7.10.3\prelude-extras-0.4.0.3-1gQpKVfMHul71LsAFgGRhv
    setup-Simple-Cabal-1.22.5.0-ghc-7.10.3.exe:
    'C:\Users\…\AppData\Local\Programs\stack\x86_64-windows\ghc-7.10.3\bin\ghc.exe'
    exited with an error:

(yes, that's right, no error message)
The mentioned log doesn't exist, there is no .stack-work directory in the temp files (any more?).

---

Update: Trying again failed for a different library. Trying again for a third time it worked!

[bergus]

Thanks, the dependency conflict reporting is much improved in the latest version indeed. When adding the compiler option now, I get:

While constructing the build plan, the following exceptions were encountered:

In the dependencies for array-0.5.1.0:
    base-4.9.0.0 must match >=4.5 && <4.9 (latest applicable is 4.8.2.0)
needed due to my-project-1.1 -> array-0.5.1.0

In the dependencies for containers-0.5.6.2:
    base-4.9.0.0 must match >=4.2 && <4.9 (latest applicable is 4.8.2.0)
needed due to my-project-1.1 -> containers-0.5.6.2

In the dependencies for deepseq-1.4.1.1:
    base-4.9.0.0 must match ==4.3.* || >=4.5 && <4.9 (latest applicable is 4.8.2.0)
needed due to my-project-1.1 -> deepseq-1.4.1.1

In the dependencies for directory-1.2.2.0:
    base-4.9.0.0 must match >=4.5 && <4.9 (latest applicable is 4.8.2.0)
needed due to my-project-1.1 -> directory-1.2.2.0

In the dependencies for filepath-1.4.0.0:
    base-4.9.0.0 must match >=4 && <4.9 (latest applicable is 4.8.2.0)
needed due to my-project-1.1 -> filepath-1.4.0.0

In the dependencies for haddock-library-1.2.1:
    base-4.9.0.0 must match >=4.5 && <4.9 (latest applicable is 4.8.2.0)
needed due to my-project-1.1 -> haddock-library-1.2.1

In the dependencies for process-1.2.3.0:
    base-4.9.0.0 must match >=4.4 && <4.9 (latest applicable is 4.8.2.0)
needed due to my-project-1.1 -> process-1.2.3.0

In the dependencies for transformers-0.4.2.0:
    base-4.9.0.0 must match >=2 && <4.9 (latest applicable is 4.8.2.0)
needed due to my-project-1.1 -> transformers-0.4.2.0

Plan construction failed.

An explicit warning on the incompatible compiler would still be nice, but at least it's specific now about base being incompatible, which should give enough hints.

[Blaisorblade]

An explicit warning on the incompatible compiler would still be nice, but at least it's specific now about base being incompatible, which should give enough hints.

FWIW, #2502 also found similar messages confusing (for stack --init), though it's not obvious how to improve on that.

[mgsloan]

Yeah, for version mismatches on wired in packages, it would make sense to let the user know that it's tied to the compiler.

Glad you like the improved output. I found that much of the old build plan errors were entirely redundant info in practice, making it really hard to pick out the important parts.