!RbXGJhHMsnQcNIDFWN:nixos.org

Haskell in Nixpkgs/NixOS

720 Members
For discussions and questions about Haskell with Nix, cabal2nix and haskellPackages in nixpkgs | Current Docs: https://haskell4nix.readthedocs.io/ | More Nix: #community:nixos.org | More Haskell: #haskell-space:matrix.org143 Servers

Load older messages


SenderMessageTime
13 Aug 2025
@artem.types:matrix.orgArtemoh, no, I do :-)18:37:24
@artem.types:matrix.orgArtemRedacted or Malformed Event19:03:51
@artem.types:matrix.orgArtemdoes 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 time19:09:09
@artem.types:matrix.orgArtem* 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 time19:21:04
@artem.types:matrix.orgArtem

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
@sternenseemann:systemli.orgsterni (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
@sternenseemann:systemli.orgsterni (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 it19:58:59
@sternenseemann:systemli.orgsterni (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
@sternenseemann:systemli.orgsterni (he/him)in the nix build?20:04:55
@artem.types:matrix.orgArtem
In reply to @sternenseemann:systemli.org
in the nix build?
Yes
20:23:05
@sternenseemann:systemli.orgsterni (he/him)which package?20:23:45
@sternenseemann:systemli.orgsterni (he/him)* which package/version?20:23:49
@artem.types:matrix.orgArtem 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
@sternenseemann:systemli.orgsterni (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.types:matrix.orgArtemit sounds like that. I'll grep for the PATH trick.21:43:20
14 Aug 2025
@sternenseemann:systemli.orgsterni (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.types:matrix.orgArtemAh, interesting00:48:44
@artem.types:matrix.orgArtem

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
@sternenseemann:systemli.orgsterni (he/him)nevermind then…01:06:46
@artem.types:matrix.orgArtembut there might be a bug in that Cabal the library can't handle BTD correctly. I f memory serves, it was primarily cabal-install feature. There may be a ticket on Cabal's bug tracker...01:12:37
@artem.types:matrix.orgArtemthe docs proceed to say that "old-style-builds" (which is what you get with the library, so this includes the Nixpkgs Haskell builder) can't handle external deps in BTD, but internal ones should be OK, which is not what we're seeing01:15:38
@artem.types:matrix.orgArtemthe PATH trick looks straightforward in the examples I see but it's not working so far with the old result ("fixpoint not found"). I'm investigating it01:29:36
@artem.types:matrix.orgArtem

in particular, that's what I have:

  liquid-fixpoint = overrideCabal (drv: {
      preCheck = ''
        export PATH=dist/build/fixpoint:$PATH     
      ''
      + (drv.preCheck or "");
    }) super.liquid-fixpoint;

if I add dist/build/fixpoint/fixpoint --help, I see the help messge from the tool. Yet, the tests fail with /bin/sh: fixpoint: not found. It looks like that PATH doesn't make it all the way through...

01:36:26
@b:chreekat.netchreekatWould using an absolute path help?06:27:37
@sternenseemann:systemli.orgsterni (he/him)I think it is necessary since the test suite changes directory sometimes: https://github.com/ucsd-progsys/liquid-fixpoint/blob/0171863c853a6076238d2697388f4ad6f2ee43b2/tests/test.hs#L181-L19910:33:42
@sternenseemann:systemli.orgsterni (he/him) export PATH="$PWD/dist/build/fixpoint:$PATH" or similar should work 10:34:13
@dandart:matrix.orgUraraka ~ Ochaco joined the room.11:41:24
@manuelbaerenz:matrix.orgManuel BärenzRedacted or Malformed Event12:03:39
@artem.types:matrix.orgArtemoh my, I should have guessed. Thanks all, liquid-fixpoint works now. I'm looking into liquidhaskell now. It currently fails because it fetches the latest version from Hackage (it's not on Stackage), and it's not going to work with GHC from the latest LTS because: (a) it's tightly coupled with the GHC version so much so they usually only support one GHC version at a time, (b) the latest from Hackage will usually support only the latest released GHC. Question: how do I request a specific version of a package from Hackage to serve as the default haskellPackages version?15:09:03
@artem.types:matrix.orgArtemthere must be examples somewhere but I'm not very good at finding the minimal one. I see overrideSrc and overrideCabal but both look a bitt low level15:10:01

Show newer messages


Back to Room ListRoom Version: 6