allow-newer in cabal.project not propagating to builds

[ocharles]

In my cabal.project I have:

allow-newer:
  mandrill:aeson

But when I try and build a component that depends on mandrill, I get:

building '/nix/store/li9l28yywakv6k1rbbgfsx24avlgx7c5-mandrill-0.5.3.5-lib-mandrill.drv'...
unpacking sources
unpacking source archive /nix/store/83ynmhrfdqh6yph0z2lc94w8vn31yxbg-mandrill-0.5.3.5.tar.gz
source root is mandrill-0.5.3.5
setting SOURCE_DATE_EPOCH to timestamp 1536162563 of file mandrill-0.5.3.5/src/Network/API/Mandrill/Webhooks.hs
patching sources
configuring
Configure flags:
--prefix=/nix/store/wqy7fv2aiqa654bcbbh77whc9rbmsvsf-mandrill-0.5.3.5-lib-mandrill lib:mandrill --package-db=clear --package-db=/nix/store/iz0npwr9r7qv8df09cis8m5ch9nfqf76-mandrill-0.5.3.5-lib-mandrill-config/package.conf.d --with-ghc=ghc --with-ghc-pkg=ghc-pkg --with-hsc2hs=hsc2hs --with-gcc=cc --with-ld=ld --with-ar=ar --with-strip=strip --disable-executable-stripping --disable-library-stripping --disable-library-profiling --disable-executable-profiling --docdir=/nix/store/vlz6szby086y8d0d7a43mipziki2fy2i-mandrill-0.5.3.5-lib-mandrill-doc/share/doc/mandrill --enable-split-sections
Configuring library for mandrill-0.5.3.5..
Warning: The flag --disable-executable-profiling is deprecated. Please use
--disable-profiling instead.
Setup: Encountered missing dependencies:
aeson >=0.7.0.3 && <1.4.0.0

/nix/store/iz0npwr9r7qv8df09cis8m5ch9nfqf76-mandrill-0.5.3.5-lib-mandrill-config/package.conf.d has aeson-1.4.4.0, which is technically out-of-bands, but I want to allow it anyway.

[ocharles]

I found that I had to add

        modules = [ { packages.mandrill.components.library.doExactConfig = true; } ];

But this wasn't at all apparent!

[angerman]

One issue with —allow-newer or —allow-older is that the plumbing interface (via Setup.hs) does not support it. I wonder if we can recover allow-newer from then plan.json and then set doExactConfig appropriately. We could also just blanket set doExactConfig for plan-to-nix generated expressions as for those we have asked cabal to compute the solution and could just trust it to do the right thing.

[ocharles]

Unfortunately I can't see anything in the plan at the moment that would let you figure this out. But why is doExactConfig not already the default? Is the point not to just use exactly what cabal new-configure produced?

[angerman]

Unfortunately I can't see anything in the plan at the moment that would let you figure this out. But why is doExactConfig not already the default? Is the point not to just use exactly what cabal new-configure produced?

doExactConfig has a non-zero cost in computing the constraints flags to be passed to cabal. Also the number of constraints flags could lead to argmax issues overflowing the limit systems put on arguments :-/

We have a patched cabal (again...) at iohk, that supports @reponse-files, and that has been upstreamed as well. Yet it will only be widely available with cabal 3.0 (and therefore ghc 8.8).

[ocharles]

Ok, cool! I am not in a rush, I would be OK if this project required Cabal 3

[angerman]

I think you can just set:

modules = [ { packages.doExactConfig = true; } ];

or

modules = [ { doExactConfig = true; } ];

and it would propagate through. There is some inheritance logic in https://github.com/input-output-hk/haskell.nix/blob/master/modules/plan.nix, which should make this possible.

[michaelpj]

I think we fixed this.