`ansi-wl-pprint` build failing

[dhess]

Hi,

Recently, ansi-wl-pprint started failing in our builds:

error: builder for '/nix/store/mqnf8ckk3kb3gznf87kdm6242d2hqbmm-ansi-wl-pprint-lib-ansi-wl-pprint-0.6.9.drv' failed with exit code 1;
--
  | last 10 log lines:
  | > setting SOURCE_DATE_EPOCH to timestamp 1000000000 of file ansi-wl-pprint-0.6.9/src-exe/Example.hs
  | > patching sources
  | > updateAutotoolsGnuConfigScriptsPhase
  | > configuring
  | > Configure flags:
  | > --prefix=/nix/store/lfwljwyqqxykwc05zln9vchczbgvl7vr-ansi-wl-pprint-lib-ansi-wl-pprint-0.6.9 lib:ansi-wl-pprint --package-db=clear --package-db=/nix/store/0frk6mwwj64j2mbbmpq4fk6kmxc8qipm-ansi-wl-pprint-lib-ansi-wl-pprint-0.6.9-config/lib/ghc-9.0.2/package.conf.d --flags=-example --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-profiling --enable-static --enable-shared --disable-coverage --enable-library-for-ghci --datadir=/nix/store/x61azrig5axjcmz7ryilsf7a90y76j0n-ansi-wl-pprint-lib-ansi-wl-pprint-0.6.9-data/share/ghc-9.0.2 --ghc-option=-fPIC --gcc-option=-fPIC
  | > Configuring library for ansi-wl-pprint-0.6.9..
  | > Error: Setup: Encountered missing or private dependencies:
  | > ansi-terminal >=0.9.1 && <0.10
  | >
  | For full logs, run 'nix log /nix/store/mqnf8ckk3kb3gznf87kdm6242d2hqbmm-ansi-wl-pprint-lib-ansi-wl-pprint-0.6.9.drv'.
  | error: 1 dependencies of derivation '/nix/store/k7pj9pf90f4w735f78kvgw0ahsbimj7b-optparse-applicative-lib-optparse-applicative-0.16.1.0-config.drv' failed to build
  | error: 1 dependencies of derivation '/nix/store/lvch274zxyv2iyr8pfhhhicrg702d305-optparse-applicative-lib-optparse-applicative-0.16.1.0.drv' failed to build

The bounds on the ansi-terminal dependency that are causing the problem are from the original Hackage upload of ansi-wl-pprint, but the latest revision of ansi-wl-pprint has updated bounds, so I'm not sure why haskell.nix is picking up the original package.

Nothing has changed on our end. I've tried ghc925 and now ghc926.

Any ideas?

[andreabedini]

I tried to reproduce the problem but haskell.nix master seems to be able to build ansi-terminal without any problem.

E.g.

$ mkdir test && cd test
$ cabal init -n -m -d ansi-wl-pprint
$ nix run github:input-output-hk/haskell.nix#hix-build -- --argstr compiler-nix-name ghc925
... bla bla ...

Few thoughts:

• Are you setting a index-state somewhere? either in nix or in cabal.project. Haskell.nix should log what index state it is using, like

Using index-state 2023-02-20T00:00:00Z

• If your Haskell.nix is not recent enough to include the revision you are interested in, you need to either bump haskell.nix or override its hackage source.
• Haskell.nix has recently got a more robust support for revisions, one more reason to try to bump haskell.nix.

Let me know how you go!

PS: in case you don't have any custom nix configuration, you can build your cabal project with the latest version of haskell.nix using nix run github:input-output-hk/haskell.nix#hix-build -- --argstr compiler-nix-name ghc925.

[dhess]

Thanks for the reply. We're using yesterday's haskell.nix (9a06294) and index-state: 2023-02-19T00:00:00Z. In any case, the last revision of ansi-wl-pprint-0.6.9 is from well over a year ago and the revision that bumped the ansi-terminal bounds is from 2020-08. This has only started happening with the last few weeks' haskell.nix, by the way.

Is there a way to force haskell.nix to rebuild/rematerialize a particular package? If our ansi-wl-pprint is cached and is an older rev, that might explain it. I think this occasionally happens with nixpkgs haskellPackages.

[andreabedini]

Could you check it you still have the problem using 0d3dea7 ? That would be right before we merged #1775.

Also, could you share the complete log message (of the failing derivation)?

[dhess]

Sorry if I've been unclear, or if I'm misunderstanding. We've been using haskell.nix for several years with this particular project. Our use of ansi-wl-pprint (via optparse-applicative) predates 0d3dea7. This issue has only come up since upgrading from 78aed6a, which works fine with index-state: 2023-02-02T00:00:00Z.

Sorry, my mistake. I see that 0d3dea7 is recent. I was confused by the date on #1775.

I'll try this and get back to you.

[dhess]

OK, yes, the problem is with 7075077.

On 0d3dea7 with ghc925 and index-state: 2023-02-08T00:00:00Z, the build works.

On 7075077 and with no other changes, the build fails on ansi-wl-pprint. The full log for the failing derivation is:

@nix { "action": "setPhase", "phase": "unpackPhase" }
unpacking sources
unpacking source archive /nix/store/swvami08dvmv9ph62r565xsw8446n2il-ansi-wl-pprint-0.6.9.tar.gz
source root is ansi-wl-pprint-0.6.9
setting SOURCE_DATE_EPOCH to timestamp 1000000000 of file ansi-wl-pprint-0.6.9/src-exe/Example.hs
@nix { "action": "setPhase", "phase": "patchPhase" }
patching sources
@nix { "action": "setPhase", "phase": "updateAutotoolsGnuConfigScriptsPhase" }
updateAutotoolsGnuConfigScriptsPhase
@nix { "action": "setPhase", "phase": "configurePhase" }
configuring
Configure flags:
--prefix=/nix/store/kzgrnj7spnj7g49v3vyxc60lcvbkngg1-ansi-wl-pprint-lib-ansi-wl-pprint-0.6.9 lib:ansi-wl-pprint --package-db=clear --package-db=/nix/store/g3hnccsdd2dirrrwpazchhmhif4gcsy9-ansi-wl-pprint-lib-ansi-wl-pprint-0.6.9-config/lib/ghc-9.0.2/package.conf.d --flags=-example --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-profiling --enable-static --enable-shared --disable-coverage --enable-library-for-ghci --datadir=/nix/store/1856bbq0jiw0601dyp125d51smi2x53f-ansi-wl-pprint-lib-ansi-wl-pprint-0.6.9-data/share/ghc-9.0.2 --ghc-option=-fPIC --gcc-option=-fPIC 
Configuring library for ansi-wl-pprint-0.6.9..
Error: Setup: Encountered missing or private dependencies:
ansi-terminal >=0.9.1 && <0.10

ansi-wl-pprint is being dragged into our project via optparse-applicative, so that might be a good place to start.

[angerman]

@dhess any chance you have a reproducer for this?

[dhess]

@angerman Not at the moment. The repo will be public sometime in the next few months but we're not quite ready for that yet. I'll try to put something together that I can share in the meantime.

[angerman]

@angerman Not at the moment. The repo will be public sometime in the next few months but we're not quite ready for that yet. I'll try to put something together that I can share in the meantime.

Great! We haven't been able to reproduce this yet. We are probably holding it wrong somehow :-(

[brprice]

We now have a reproducer we can share: https://github.com/hackworthltd/repro-haskell.nix-1850. Running nix build .#repro:test:repro-test fails in the same way as above.

It does not appear to be a problem with ansi-wl-pprint itself, but with revisions generally (I have seen similar failures for the unix package). It also appears to be a bad interaction with our workaround for #839:
if the following line in flake.nix is commented out packages.repro.components.tests.repro-test.build-tools = [ final.haskell-nix.snapshots."lts-19.9".tasty-discover ]; then nix builds work fine, but cabal builds in a nix-develop shell cannot find tasty-discover. (Using a newer snapshot does not fix the problem.)

I have not yet attempted to minimise the reproducer. Let me know if that would be helpful and I'll try to find some time to do so.

[hamishmack]

Please try:

packages.repro.components.tests.repro-test.build-tools = [ (final.haskell-nix.tool ghcVersion "tasty-discover" {}) ];

[andreabedini]

@brprice @dhess Thank you. The reprocible example let us understood exactly where the problem was (#1775 broke stackage 😬 🙀 ). Hamish workaround above should fix the problem for you. Let us know whether this is the case. I'll open a separate issue for the problem we have discovered.

[dhess]

Hi all, I can confirm that @hamishmack's fix does the trick for us — everything is building again.

FYI, there was no good reason we were using Stackage snapshots for this in the first place, and we'll now stick with this fix until #839 is resolved. In any case, we're good to go now and there's no urgency to fix the Stackage issue in #1857 on our behalf.

Thank you for all the help, everyone! And thanks again for this fantastic project.