new-build does not find solution where configure finds one easily

[edsko]

Running cabal-nix new-build in the hackage-security directory, with ghc 7.4.2 active, gives me

# cabal-nix new-build
Resolving dependencies...
cabal-nix: Could not resolve dependencies:
trying: Cabal-1.23.0.0 (user goal)
trying: unix-2.5.1.1/installed-296... (dependency of Cabal-1.23.0.0)
next goal: hackage-security (user goal)
rejecting: hackage-security-0.5.0.0 (conflict: unix =>
bytestring==0.9.2.1/installed-004..., hackage-security => bytestring>=0.10.2
&& <0.11)
rejecting: hackage-security-0.3.0.0, hackage-security-0.2.0.0,
hackage-security-0.1.0.0 (constraint from user target requires ==0.5.0.0)
Dependency tree exhaustively searched.

Explicitly telling it to use a newer version of unix just yields the next problem:

# cabal-nix new-build --constraint='unix>=2.6'
Resolving dependencies...
cabal-nix: Could not resolve dependencies:
trying: Cabal-1.23.0.0 (user goal)
next goal: process (dependency of Cabal-1.23.0.0)
rejecting: process-1.1.0.1/installed-f00... (conflict: unix==2.7.1.0, process
=> unix==2.5.1.1/installed-296...)
trying: process-1.4.1.0
trying: example-client-0.1.0.0 (user goal)
next goal: optparse-applicative (dependency of example-client-0.1.0.0)
rejecting: optparse-applicative-0.12.0.0 (conflict: process==1.4.1.0,
optparse-applicative => process>=1.0 && <1.4)
rejecting: optparse-applicative-0.11.0.2, optparse-applicative-0.11.0.1,
optparse-applicative-0.11.0 (conflict: process==1.4.1.0, optparse-applicative
=> process>=1.0 && <1.3)
rejecting: optparse-applicative-0.10.0, optparse-applicative-0.9.1.1,
optparse-applicative-0.9.1, optparse-applicative-0.9.0,
optparse-applicative-0.8.1, optparse-applicative-0.8.0.1,
optparse-applicative-0.8.0, optparse-applicative-0.7.0.2,
optparse-applicative-0.7.0.1, optparse-applicative-0.7.0,
optparse-applicative-0.6.0, optparse-applicative-0.5.2.1,
optparse-applicative-0.5.2, optparse-applicative-0.5.1,
optparse-applicative-0.5.0, optparse-applicative-0.4.3,
optparse-applicative-0.4.2, optparse-applicative-0.4.1,
optparse-applicative-0.4.0, optparse-applicative-0.3.2,
optparse-applicative-0.3.1, optparse-applicative-0.3.0,
optparse-applicative-0.2.0, optparse-applicative-0.1.1,
optparse-applicative-0.1.0, optparse-applicative-0.0.1 (conflict:
example-client => optparse-applicative>=0.11)
Dependency tree exhaustively searched.

I did not try further from there; the standard configure just gives

# cabal-std install --dry-run
/Users/e/opt/cabal/cabal-1.22.4.0 install --dry-run
Resolving dependencies...
In order, the following would be installed (use -v for more details):
bytestring-0.10.6.0
base64-bytestring-1.0.0.1
binary-0.8.0.0
byteable-0.1.1
cryptohash-0.11.6
ed25519-0.0.5.0
text-1.2.1.3
transformers-0.4.3.0 (latest: 0.5.0.0)
mtl-2.2.1
parsec-3.1.9
network-uri-2.6.0.3
unix-2.7.1.0
directory-1.2.5.0
network-2.6.2.1
process-1.4.1.0
Cabal-1.23.0.0
tar-0.4.2.2
zlib-0.6.1.1
hackage-security-0.5.0.0

[edsko]

Actually, I think this might be because cabal-nix is trying to find a solution that involves all packages in the project, whether you build them or not. Adding example-client into the mix breaks standard cabal as well.

[ezyang]

That would do it, because the point of nix is deterministic configure over the project.

[edsko]

Hmmm, actually, removing my .cabal_sandbox completely enables standard cabal to find a solution after all:

bytestring-0.10.6.0
base64-bytestring-1.0.0.1
binary-0.8.0.0
byteable-0.1.1
bytestring-builder-0.10.6.0.0
cryptohash-0.11.6
data-default-class-0.0.1
ed25519-0.0.5.0
random-1.1
stm-2.4.4.1
text-1.2.1.3
blaze-builder-0.4.0.1
cookie-0.4.1.6
hashable-1.2.3.3
case-insensitive-1.2.0.5
http-types-0.9
mime-types-0.1.0.6
transformers-0.4.3.0 (latest: 0.5.0.0)
mtl-2.2.1
parsec-3.1.9
network-uri-2.6.0.3
transformers-compat-0.4.0.4
exceptions-0.8.0.2
unix-2.7.1.0
ansi-terminal-0.6.2.3
ansi-wl-pprint-0.6.7.3
directory-1.2.5.0
network-2.6.2.1
HTTP-4000.2.22
process-1.3.0.0 (latest: 1.4.1.0)
Cabal-1.23.0.0
optparse-applicative-0.12.0.0
tar-0.4.2.2
zlib-0.6.1.1
hackage-security-0.5.0.0
hackage-security-HTTP-0.1.0.2
hackage-security-curl-0.1.0.0
streaming-commons-0.1.15
http-client-0.4.26.1
hackage-security-http-client-0.1.0.0
example-client-0.1.0.0

So I guess something weird is happening here after all. (Wiping the dist-newstyle directory has no effect on new-build finding a solution or not). Leaving this open, although I'm not sure it's really a bug or something else that I'm not taking into account.

[edsko]

Ok, this was my fault after all; one of the packages in the project had a constraint on containers >= 0.5, which clashed with template-haskell on ghc 7.4. The error from the solver was very unhelpful here, but --reorder-goals made it a lot clearer. Seeing some strange behaviour still now but I'll open a separate ticket about that.