intero fails to install when the stack resolver has incompatible boot packages
Opened this issue · 10 comments
On startup, just fails.
intero-0.1.32: configure
intero-0.1.32: build
-- While building custom Setup.hs for package intero-0.1.32 using:
/home/hasufell/.stack/setup-exe-cache/x86_64-linux-tinfo6/Cabal-simple_mPHDZzAJ_2.0.1.0_ghc-8.2.2 --builddir=.stack-work/dist/x86_64-linux-tinfo6/Cabal-2.0.1.0 bui
ld --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always"
Process exited with code: ExitFailure 1
Logs have been written to: .../intero-0.1.32.log
Configuring intero-0.1.32...
Warning:
This package indirectly depends on multiple versions of the same package. This is very likely to cause a compile failure.
package ghci (ghci-8.2.2) requires binary-0.8.5.1
package ghc-boot (ghc-boot-8.2.2) requires binary-0.8.5.1
package ghc (ghc-8.2.2) requires binary-0.8.5.1
package ghci (ghci-8.2.2-JG49OKW8gsQFdWJQf6tmU0) requires binary-0.8.5.1-2jjzTJ14Adx8SkxPTQoTtW
package ghc-boot (ghc-boot-8.2.2-8qlL7gZ9Qhe2GONp97s6QO) requires binary-0.8.5.1-2jjzTJ14Adx8SkxPTQoTtW
package hpc (hpc-0.6.0.3) requires containers-0.5.10.2
package hoopl (hoopl-3.10.2.2) requires containers-0.5.10.2
package ghci (ghci-8.2.2) requires containers-0.5.10.2
package ghc (ghc-8.2.2) requires containers-0.5.10.2
package binary (binary-0.8.5.1) requires containers-0.5.10.2
package intero (intero-0.1.32) requires containers-0.5.11.0-74jiVtUSISeGR33AtpmPdk
package haskeline (haskeline-0.7.4.2-LpoCrOJTiaLGBAaD2qdwBn) requires containers-0.5.11.0-74jiVtUSISeGR33AtpmPdk
package ghci (ghci-8.2.2-JG49OKW8gsQFdWJQf6tmU0) requires containers-0.5.11.0-74jiVtUSISeGR33AtpmPdk
package binary (binary-0.8.5.1-2jjzTJ14Adx8SkxPTQoTtW) requires containers-0.5.11.0-74jiVtUSISeGR33AtpmPdk
package ghci (ghci-8.2.2) requires ghc-boot-8.2.2
package ghc (ghc-8.2.2) requires ghc-boot-8.2.2
package ghci (ghci-8.2.2-JG49OKW8gsQFdWJQf6tmU0) requires ghc-boot-8.2.2-8qlL7gZ9Qhe2GONp97s6QO
package ghc (ghc-8.2.2) requires ghci-8.2.2
package intero (intero-0.1.32) requires ghci-8.2.2-JG49OKW8gsQFdWJQf6tmU0
Preprocessing executable 'intero' for intero-0.1.32..
Building executable 'intero' for intero-0.1.32..
[ 1 of 10] Compiling Intero.Compat ( src/Intero/Compat.hs, .stack-work/dist/x86_64-linux-tinfo6/Cabal-2.0.1.0/build/intero/intero-tmp/Intero/Compat.o )
/tmp/stack5794/intero-0.1.32/src/Intero/Compat.hs:72:26: error:
• Couldn't match type ‘containers-0.5.10.2:Data.Graph.SCC
ModSummary’
with ‘SCC.SCC ModSummary’
NB: ‘SCC.SCC’
is defined in ‘Data.Graph’ in package ‘containers-0.5.11.0’
‘containers-0.5.10.2:Data.Graph.SCC’
is defined in ‘Data.Graph’ in package ‘containers-0.5.10.2’
Expected type: Bool
-> [ModSummary] -> Maybe ModuleName -> [SCC.SCC ModSummary]
Actual type: Bool
-> [ModSummary]
-> Maybe ModuleName
-> [containers-0.5.10.2:Data.Graph.SCC ModSummary]
• In the expression: topSortModuleGraph
In an equation for ‘ghc_topSortModuleGraph’:
ghc_topSortModuleGraph = topSortModuleGraph
|
72 | ghc_topSortModuleGraph = GHC.topSortModuleGraph
| ^^^^^^^^^^^^^^^^^^^^^^
This is a bug with upstream intero, you may want to post an issue there.
That you have multiple versions of containers is troubling.
That you have multiple versions of containers is troubling.
Well, that's stacks problem not mine. I'm not manually installing random libraries. That's all stacks doing.
Can you post the resolver you're using? I'm curious if I can reproduce the issue locally.
resolver: lts-11.13
extra-deps:
- happy-1.19.9@rev:2
- containers-0.5.11.0
- IfElse-0.85
compiler: ghc-8.2.2
compiler-check: match-exactThe problem is that you're specifying a newer containers than is compatible with the GHC version you're using. This is OK as long as nothing else in the dependency tree depends on GHC as a library, which intero does. containers-0.5.11.0 is intended for use with GHC 8.4.
That sounds like a bug.
It's an unfortunate downside of how dependencies are managed with GHC. This comment has more explanation and information, and the issue thread contains more of the trade-offs.
In short, you can't depend on containers-0.5.11.0 and also depend on a package bundled with GHC 8.2.2 because GHC 8.2.2 requires containers-0.5.10 explicitly, and GHC comes with it's own version of containers.
As a workaround, you can either use ghc-8.4.3 and containers-0.5.11.0 (now available as part of the lts-12 resolver), or you can use ghc-8.2.2 and the older containers.
Or, as a third workaround (this may or may not work), you can comment out the containers extra-dep, do stack build intero to copy the executable to your project, and then uncomment the containers extra-dep. This will build intero executable with the appropriate containers for the GHC version you're using, and then let you use the newer containers in your library.
intero-neovim can copy what the emacs package does for this: https://github.com/chrisdone/intero/blob/60e2e3f76f647b20d9de8418f9576ea157e21864/elisp/intero.el#L2224..L2231
(let ((default-directory (make-temp-file "intero" t)))
(intero-call-stack
nil (current-buffer) t nil "build"
"--copy-compiler-tool"
(concat "intero-" intero-package-version)
"--flag" "haskeline:-terminfo"
"--resolver" (concat "ghc-" ghc-version)
"ghc-paths-0.1.0.9" "mtl-2.2.2" "network-2.7.0.0" "random-1.1" "syb-0.7"))- Build intero in a temporary directory, away from the user's project directory: this avoids conflicting with their custom package versions like containers.
- Pass
--copy-compiler-toolso that it's only built once for that GHC version and will be available in any project with that GHC version.
fantastic, thank you! 😄
@hasufell I am going to edit the title to make it more clear what the problem is.
thanks @chrisdone