| 13 Aug 2025 |
emily | instead it's something you need to wrap on later | 18:22:55 |
emily | so it's unambiguously a checkInputs case. it's just that checkInputs sucks to use for executables. | 18:23:04 |
Alyssa Ross | I see! | 18:23:04 |
Alyssa Ross | Okay, then this is indeed a check input, and testSystemDepends should be fine. | 18:23:31 |
emily | arguably we should be patching in the path to Z3 in the library code | 18:23:38 |
emily | in which case there would be no check inputs needed at all | 18:23:47 |
emily | (and no wrappers needed for downstream users) | 18:23:52 |
emily | but that might not be desirable. since you might want to use another backend at runtime | 18:24:02 |
emily | so having it in the closure of smtlib-backends-process is likely suboptimal | 18:24:17 |
emily | (does GHC cross even work in Nixpkgs…) | 18:24:39 |
Artem | if I unbreak certain Haskell package (e.g. by adding jailbreaks and alike in configuration-common.nix), do I remove broken=false; from hackage-packages.nix in the same commit that I want to submit as a PR? | 18:28:55 |
Artem | ah, I guess I update configuration-hackage2nix/broken.yaml, sorry | 18:33:08 |
Artem | oh, no, I do :-) | 18:37:24 |
Artem | Redacted or Malformed Event | 19:03:51 |
Artem | does Haskell builder understand build-tool-depends in cabal files? I'm seeing a test component that has BTD on an executable in the same package and it can't find it at run time | 19:09:09 |
Artem | * Does Haskell builder understand build-tool-depends in cabal files? I'm seeing a test component that has BTD on an executable in the same package and it can't find it at run time | 19:21:04 |
Artem | That's the liquid-fixpoint package, its "test" test suite appears to call to the "fixpoint" executable from the same package but nix-build arrives at:
...
Running phase: checkPhase
Running 2 test suites...
Test suite test: RUNNING...
/bin/sh: fixpoint: not found
| 19:21:05 |
sterni (he/him) | Artem: you need to add the build directory to PATH before execution since Cabal won't do it for you unfortunately | 19:58:37 |
sterni (he/him) | there should probably be a shorthand for it, but you can just grep configuration-nix.nix for PATH to see how to do it | 19:58:59 |
sterni (he/him) | emily: Alyssa Ross: See https://nixos.org/manual/nixpkgs/unstable/#haskell-derivation-deps for input specificication in haskellPackages. Everything is eventually mapped to buildInputs, propagatedBuildInputs and nativeBuildInputs. Using checkInputs and friends is not necessary since that is basically a shorthand for adding lib.optionals doCheck [ … ] to buildInputs/nativeBuildInputs and we have to conditionalize loads on doCheck anyways. | 20:02:03 |
sterni (he/him) | in the nix build? | 20:04:55 |
Artem | In reply to @sternenseemann:systemli.org in the nix build? Yes | 20:23:05 |
sterni (he/him) | which package? | 20:23:45 |
sterni (he/him) | * which package/version? | 20:23:49 |
Artem | sterni: liquid-fixpoint. Don't worry: you answered all questions I had so far. Now I need to try what you suggested. | 21:38:54 |
sterni (he/him) | Artem: ah I think this is a Cabal bug where it doesn't add the tool to PATH and Nix won't do it because it's from the same package, but I'd need to check | 21:40:33 |
Artem | it sounds like that. I'll grep for the PATH trick. | 21:43:20 |
| 14 Aug 2025 |
sterni (he/him) | Artem: I guess it is not a bug, actually. build-tool-depends is only available while building, but during test execution it doesn't have to/shouldn't be. | 00:38:18 |
Artem | Ah, interesting | 00:48:44 |
Artem | sterni: funny enough, the documentation for BTD seems to bless this usage:
A list of Haskell executables needed to build this component. Executables are provided during the whole duration of the component, so this field can be used for executables needed during test-suite as well.
https://cabal.readthedocs.io/en/3.16/cabal-package-description-file.html#pkg-field-build-tool-depends
| 01:03:13 |