hspec-core unconditionally depends on the ghc package which pins down versions of ghc boot libraries

[arybczak]

Can you please gate the vendored libraries behind a flag so they don't have to be forced?

[arybczak]

Nevermind, the solver was picking outdated version of hspec-core :/

[sol]

Nevermind, the solver was picking outdated version of hspec-core :/

I'm puzzled how this could happen. Which exact version was picked? Are we missing a Hackage revisions that prevents this version from being picked?

[arybczak]

Cabal is picking hspec 2.9.2 because it's the latest version that doesn't depend on ghc.

I have a cabal.project.freeze file that specifies versions of ghc boot dependencies (e.g. directory) different than the ones provided by ghc 9.2.4 (the one I'm using) and that doesn't work because hspec depends on ghc and ghc depends on different versions of these libraries, so any version of hspec that depends on ghc will be incompatible with the freeze file.

The best option would be for hspec-core to get rid of the ghc dependency as it's generally problematic (there's also #750, though I'm not sure how relevant that is).

[sol]

Cabal is picking hspec 2.9.2 because it's the latest version that doesn't depend on ghc.

So we need a Hackage revisions for 2.9.2 and older, right? From what I see @andreasabel already added revisions, but apparently they are in inaccurate?

The best option would be for hspec-core to get rid of the ghc dependency as it's generally problematic (there's also #750, though I'm not sure how relevant that is).

ghc is used to parse expected/actual values so that they can be pretty-printed for nicer output and diffs when a test fails.

We could try to make this dependency optional by using an automatic flag. PRs welcome.

[arybczak]

So we need a Hackage revisions for 2.9.2 and older, right?

Revisions for what exactly? 🤔

We could try to make this dependency optional by using an automatic flag. PRs welcome.

Sounds good, see #753.

[sol]

So we need a Hackage revisions for 2.9.2 and older, right?

Revisions for what exactly? 🤔

From what I understood: hspec-core-2.9.2 does not build with GHC 9.2.*, is that correct? Just to be sure, I'm assuming here that you did not pass --allow-newer or something to Cabal. Is that correct?

So we need a Hackage revision to reflect this somehow, probably by constraining the version of base.

[sol]

Revisions for what exactly? thinking

From what I understood: hspec-core-2.9.2 does not build with GHC 9.2.*, is that correct?

@arybczak I can't reproduce this. Can you provide:

1. The exact versions of pinned boot dependencies you are using
2. The compiler error you are getting

[arybczak]

From what I understood: hspec-core-2.9.2 does not build with GHC 9.2.*, is that correct?

No, hspec-core-2.9.2 doesn't build with GHC 9.4 because of outdated vendored-in async package and any newer version doesn't build with my setup because it depends on the ghc package.

So fair enough, adding base constraint to 2.9.2 will make Cabal fail earlier with GHC 9.4, but that's a separate issue.

I can't reproduce this.

For a demonstration of a problem it's enough to create a dummy cabal project with cabal init and then add to build-depends hspec-core == 2.10.6 and directory == 1.3.8.0.

Now, see:

GHC 9.2.4:

unknown@electronics hspec-test $ cabal build -w ghc-9.2.4 --minimize-conflict-set
Resolving dependencies...
Error: cabal: Could not resolve dependencies:
[__0] trying: hspec-test-0.1.0.0 (user goal)
[__1] trying: hspec-core-2.10.6 (dependency of hspec-test)
[__2] next goal: ghc (dependency of hspec-core)
[__2] rejecting: ghc-9.2.4/installed-9.2.4 (conflict: hspec-test =>
directory==1.3.8.0, ghc => directory==1.3.6.2/installed-1.3.6.2)
[__2] trying: ghc-9.4.2
[__3] next goal: ghci (dependency of ghc)
[__3] rejecting: ghci-9.2.4/installed-9.2.4 (conflict: ghc => ghci==9.4.2)
[__3] skipping: ghci-8.10.2, ghci-8.10.1, ghci-8.8.3, ghci-8.8.1, ghci-8.6.5,
ghci-8.6.4, ghci-8.6.1, ghci-8.4.4, ghci-8.4.3, ghci-8.4.2, ghci-8.4.1,
ghci-8.2.2, ghci-8.2.1, ghci-8.0.2, ghci-8.0.1 (has the same characteristics
that caused the previous version to fail: excluded by constraint '==9.4.2'
from 'ghc')
[__3] fail (backjumping, conflict set: ghc, ghci)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: ghc, hspec-test, ghci, hspec-core,
base, ghc-boot

GHC 9.4.3:

unknown@electronics hspec-test $ cabal build -w ghc-9.4.3 --minimize-conflict-set
Resolving dependencies...
Error: cabal: Could not resolve dependencies:
[__0] trying: hspec-test-0.1.0.0 (user goal)
[__1] trying: hspec-core-2.10.6 (dependency of hspec-test)
[__2] next goal: ghc (dependency of hspec-core)
[__2] rejecting: ghc-9.4.3/installed-9.4.3 (conflict: hspec-test =>
directory==1.3.8.0, ghc => directory==1.3.7.1/installed-1.3.7.1)
[__2] trying: ghc-9.4.2
[__3] next goal: ghci (dependency of ghc)
[__3] rejecting: ghci-9.4.3/installed-9.4.3 (conflict: ghc => ghci==9.4.2)
[__3] skipping: ghci-8.10.2, ghci-8.10.1, ghci-8.8.3, ghci-8.8.1, ghci-8.6.5,
ghci-8.6.4, ghci-8.6.1, ghci-8.4.4, ghci-8.4.3, ghci-8.4.2, ghci-8.4.1,
ghci-8.2.2, ghci-8.2.1, ghci-8.0.2, ghci-8.0.1 (has the same characteristics
that caused the previous version to fail: excluded by constraint '==9.4.2'
from 'ghc')
[__3] fail (backjumping, conflict set: ghc, ghci)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: ghc, hspec-test, hspec-core, base,
ghci

This is because ghc package is not reinstallable and it was compiled with a particular directory version, hence if you depend on the ghc package, you can only use versions of its dependencies it was compiled with.

Until the ghc package is made reinstallable, the only workaround for this problem is to not depend on the ghc package.

[andreasabel]

Until the ghc package is made reinstallable, the only workaround for this problem is to not depend on the ghc package.

I think cabal is rather moving into the opposite direction, making ghc non-upgradeable by definition:

• ghc, ghc-boot, ghci packages should be non-upgradable (#8489) haskell/cabal#8501