'How to fail fast(er) when trying to update a package in Haskell?
Problem
In a very used library haddock we have
#if MIN_VERSION_ghc(9,2,0) && !MIN_VERSION_ghc(9,3,0)
Those hidden dependencies make it into the built binary.
So, say, haddocset builds just fine thanks to stack.yaml targeting lts-12.0, with extra-dependency
extra-deps:
- haddock-api-2.20.0
- haddock-library-1.6.0
And then when running the actual executable
haddock: internal error: /Users/nicolas/.stack/programs/x86_64-osx/ghc-8.4.4/lib/ghc-8.4.4/settings: openFile: does not exist (No such file or directory)
Updating with Stackage
To update haddocset to lts-18.25 as far as I understand I have to update the "extra-deps" which entails to
- check GHC version (in my case from LTS-18.25 so ghc 8.10.7).
- check which version of the
baselibrary 8.10.7 comes with in the release notes so4.14.3.0 - browse through hackage to find which version of that package has a compatible
baselibrary so its haddock-api-2.24.0 - same for finding
hsdev-0.3.1.4hdocs-0.4.4.1 - then
stack buildsuggests to add
- MonadCatchIO-transformers-0.3.1.3@sha256:468a6f12fd3821d2ab6301cc3543930c05e5117118917c6857ea383bdcc96c54,1127
- ghc-syb-utils-0.2.3.3@sha256:fc4cd944bbd4d5160b2ee8bb458974a135c0abbd9941fb6e5f9180164efd091a,1302
which look compatible on hackage.
Then I get an error from ghc-syb-utils
ghc-syb-utils > /private/var/folders/nw/tfpqw8w97hq8kw7kvf1qst2w0000gn/T/stack-03a7d85958fa8f57/ghc-syb-utils-0.2.3.3/GHC/SYB/Utils.hs:258:64: error:
ghc-syb-utils > • Could not deduce (Outputable (HsOverLit RdrName))
which says something on ghc-syb-utils (ghc (>=7.10 && <8.6)) and something else on github ("GHC 8.0 or later is not supported")
So I can't build this binary for 8.10.7/LTS-18.25.
Updating with Cabal
I am no expert at all on cabal, because having random build plan depending on what is currently published is both totally mad for end-users, and a great freedom for library authors who want their updates to be picked up everywhere silently. And I am just a user here, wanting to install a binary.
Of course the project haddocset as it is does not build with cabal anymore, although nothing has changed, because (I think) of the said madness, either with v1-build or v2-build prayer. Maybe some way do exist. I just don't know.
If in the cabal file one set the bounds for base and ghc, relax the upper bounds for the other dependencies, or else, there are only the usual message about "backjumping" from those invocation
🕙[ 04:42:14 ] [💣 1] ❯ cabal-3.4.1.0 v1-build
Resolving dependencies...
Warning: solver failed to find a solution:
Could not resolve dependencies:
[__0] trying: haddocset-0.4.3 (user goal)
[__1] next goal: base (dependency of haddocset)
[__1] rejecting: base-4.12.0.0/installed-4.12.0.0 (conflict: haddocset =>
base>=4.14.3.0 && <5)
[__1] fail (backjumping, conflict set: base, haddocset)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: haddocset, base
Trying configure anyway.
Configuring haddocset-0.4.3...
cabal-3.4.1.0: Encountered missing or private dependencies:
base >=4.14.3.0 && <5,
conduit,
conduit-extra,
haddock-api >=2.15,
hsdev,
http-types,
resourcet,
sqlite-simple
🕙[ 04:42:11 ] [💣 130] ❯ cabal-3.4.1.0 v2-build
Resolving dependencies...
cabal-3.4.1.0: Could not resolve dependencies:
[__0] trying: haddocset-0.4.3 (user goal)
[__1] next goal: base (dependency of haddocset)
[__1] rejecting: base-4.12.0.0/installed-4.12.0.0 (conflict: haddocset =>
base>=4.14.3.0 && <5)
[__1] rejecting: base-4.16.0.0, base-4.15.1.0, base-4.15.0.0, base-4.14.3.0,
base-4.14.2.0, base-4.14.1.0, base-4.14.0.0, base-4.13.0.0, base-4.12.0.0,
base-4.11.1.0, base-4.11.0.0, base-4.10.1.0, base-4.10.0.0, base-4.9.1.0,
base-4.9.0.0, base-4.8.2.0, base-4.8.1.0, base-4.8.0.0, base-4.7.0.2,
base-4.7.0.1, base-4.7.0.0, base-4.6.0.1, base-4.6.0.0, base-4.5.1.0,
base-4.5.0.0, base-4.4.1.0, base-4.4.0.0, base-4.3.1.0, base-4.3.0.0,
base-4.2.0.2, base-4.2.0.1, base-4.2.0.0, base-4.1.0.0, base-4.0.0.0,
base-3.0.3.2, base-3.0.3.1 (constraint from non-upgradeable package requires
installed instance)
[__1] fail (backjumping, conflict set: base, haddocset)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: base, haddocset
Question
What are the fastest way, either with stack or with cabal, to spot that there are real code issue in ghc-syb-utils, so that it's not just a matter of updating dependencies ?
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
| Solution | Source |
|---|
