'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 base library 8.10.7 comes with in the release notes so 4.14.3.0
  • browse through hackage to find which version of that package has a compatible base library so its haddock-api-2.24.0
  • same for finding hsdev-0.3.1.4 hdocs-0.4.4.1
  • then stack build suggests 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