input-output-hk/haskell.nix

Shells are more prescriptive about using the installed packages

michaelpj opened this issue · 0 comments

michaelpj commented

I'm unsure if this is a behaviour change or if I'm just noticing it now.

In the past, if I was in a haskell.nix shell; changed a package bound; and ran cabal build; then cabal would rebuild the packages that it needed if they didn't line up with the pre-prepared package db. We even have an option for not doing that: exactDeps.

It seems to me that the behaviour has become a bit more "exact-deps-like" by default.

To reproduce:

This gives a strange error:

Resolving dependencies...
Error: cabal: Could not resolve dependencies:
[__0] trying: filemanip-0.3.6.3 (user goal)
[__1] trying: base-4.18.1.0/installed-4.18.1.0 (dependency of filemanip)
[__2] trying: plutus-benchmark-0.1.0.0 (user goal)
[__3] trying: cardano-crypto-class-2.1.4.0/installed-JdpmIlCMzvQIUKtYkou7UC
(dependency of plutus-benchmark)
[__4] trying: aeson-2.1.2.1/installed-DAe6GBc5EOiwc9G88hI9U (dependency of
cardano-crypto-class)
[__5] next goal: plutus-tx (user goal)
[__5] rejecting: plutus-tx-1.22.0.0 (conflict: cardano-crypto-class =>
aeson==2.1.2.1/installed-DAe6GBc5EOiwc9G88hI9U, plutus-tx => aeson>=2.2)
[__5] rejecting: plutus-tx-1.20.0.0, plutus-tx-1.19.0.0, plutus-tx-1.18.0.0,
plutus-tx-1.17.0.0, plutus-tx-1.16.0.0, plutus-tx-1.15.0.1,
plutus-tx-1.15.0.0, plutus-tx-1.14.0.0, plutus-tx-1.13.0.0,
plutus-tx-1.12.0.0, plutus-tx-1.11.0.0, plutus-tx-1.10.0.0, plutus-tx-1.9.1.0,
plutus-tx-1.9.0.0, plutus-tx-1.8.0.0, plutus-tx-1.7.0.0, plutus-tx-1.6.0.0,
plutus-tx-1.5.0.2, plutus-tx-1.5.0.0, plutus-tx-1.4.0.0, plutus-tx-1.3.0.0,
plutus-tx-1.2.0.0, plutus-tx-1.1.1.0, plutus-tx-1.1.0.0, plutus-tx-1.0.0.0
(constraint from user target requires ==1.22.0.0)
[__5] fail (backjumping, conflict set: cardano-crypto-class, plutus-tx)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: plutus-tx, aeson, base,
cardano-crypto-class, plutus-benchmark, filemanip
Try running with --minimize-conflict-set to improve the error message.

cardano-crypto-class does not bound aeson explicitly. So it looks to me like what is happening is that we are forced into picking the installed cardano-crypto-class which forces the installed aeson-2.1, thus leading to a conflict. But why can't cabal pick a newer aeson and rebuild cardano-crypto-class? I think it used to 🤔

Exiting nix develop and running it again reveals a real conflict with inline-r, but this is irrelevant: even if you resolve the conflict (with allow-newer: inline-r:aeson), the above problem still occurs.