Strange solver behaviour

[edsko]

I don't know if this is expected behaviour or not. I finally managed to build the hackage-security project using new-build on 7.4 after lowering a bound on containers. My project file now looks like:

packages: cabal/Cabal/Cabal.cabal,
          cabal/cabal-install/cabal-install.cabal,
          -- hackage-security
          hackage-security/example-client/example-client.cabal,
          hackage-security/hackage-repo-tool/hackage-repo-tool.cabal,
          hackage-security/hackage-root-tool/hackage-root-tool.cabal,
          hackage-security/hackage-security/hackage-security.cabal,
          hackage-security/hackage-security-curl/hackage-security-curl.cabal,
          hackage-security/hackage-security-HTTP/hackage-security-HTTP.cabal,
          hackage-security/hackage-security-http-client/hackage-security-http-client.cabal,
          hackage-security/precompute-fileinfo/precompute-fileinfo.cabal,
          -- tar
          tar/tar.cabal,
          -- hackage-server
          hackage-server/hackage-server.cabal

package hackage-security
This   tests: True

package cabal-install
  tests: True

package hackage-server
  tests: True

package text-icu
  extra-include-dirs: /Users/e/homebrew/Cellar/icu4c/54.1/include
  extra-lib-dirs: /Users/e/homebrew/Cellar/icu4c/54.1/lib

Running cabal-nix new-build in the hackage-security directory works. However, running cabal-nix new-build --reorder-goals instead tries to build different packages (which is not unexpected, I guess), including (and this I am somewhat surprised about) Cabal-1.22.1.1:

# cabal-nix new-build  --reorder-goals
Resolving dependencies...
In order, the following will be built (use -v for more details):
Cabal-1.22.1.1
Cabal-1.23.0.0
tar-0.4.2.2
unbounded-delays-0.1.0.9
tasty-0.11.0.2
tasty-hunit-0.9.2
hackage-security-0.5.0.0

Cabal-1.22 subsequently fails to build on 7.4:

/Users/e/wt/projects/tuf/dist-newstyle/tmp/Cabal-46022/Cabal-1.22.1.1/Distribution/License.hs:60:8:
    Could not find module `GHC.Generics'
    It is a member of the hidden package `ghc-prim'.
    Perhaps you need to add `ghc-prim' to the build-depends in your .cabal file.
    Use -v to see a list of the files searched for.

but I'm not sure why it's building two versions of Cabal here. Adding a constraint on Cabal, as well as some other constraints to help the solver along, to the cabal.project file:

constraint: Cabal >= 1.23
constraint: bytestring >= 0.10.2
constraint: unix >= 2.6
constraint: binary >= 0.6 && < 0.8
constraint: process < 1.4
constraint: time >= 1.4.2
constraint: directory >= 1.2

yields the following solver error:

# cabal-nix new-build  --reorder-goals
Resolving dependencies...
cabal-nix: Could not resolve dependencies:
trying: Cabal-1.23.0.0 (user goal)
trying: cabal-install-1.23.0.0 (user goal)
next goal: cabal-install-setup.Cabal (dependency of cabal-install-1.23.0.0)
rejecting: cabal-install-setup.Cabal-1.23.0.0 (multiple instances)
rejecting: cabal-install-setup.Cabal~>Cabal-1.23.0.0 (conflict: cabal-install
=> cabal-install-setup.Cabal>=1.10 && <1.23)
rejecting: cabal-install-setup.Cabal-1.22.5.0,
cabal-install-setup.Cabal-1.22.4.0, ... lots of versions ... (constraint from project config TODO requires
>=1.23)
Dependency tree exhaustively searched.

It's this line that confuses me:

rejecting: cabal-install-setup.Cabal~>Cabal-1.23.0.0 (conflict: cabal-install
=> cabal-install-setup.Cabal>=1.10 && <1.23)

Why would the setup dependency of cabal-install be on Cabal < 1.23?

[edsko]

(I just noticed that on 7.8 even without --reorder-goals it's also building Cabal-1.20, in addition to Cabal-1.23; it might have done the same on 7.4, I don't know. Doesn't change the question.)

[edsko]

(And yes, I realize I should be the one to understand this one, having implemented setup dependencies. But I don't think we changed the requirements on setup dependencies for packages without an explicit setup dependencies section, which cabal-install does not have, because we did not know which constraints to generate. I think @dcoutts however did change that behaviour in the nix-local-build branch, if I am not mistaken.)

[ezyang]

I reported a similar Cabal issue #2963 and Duncan gave the rationale why this was occurring. I believe that you can fix this by making cabal-install require a version of Cabal (in the cabal-version field) that is more recent than 1.22 and giving it a setup-depends.

[edsko]

Hmmm, I see. In that case, #3003 is somewhat relevant.