| 13 Aug 2025 |
 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 |
| sterni (he/him) | nevermind then… | 01:06:46 |
| Artem | but 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 | the 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 seeing | 01:15:38 |
| Artem | the 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 it | 01:29:36 |
| Artem | 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 |
 chreekat | Would using an absolute path help? | 06:27:37 |
| sterni (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-L199 | 10:33:42 |
| sterni (he/him) | export PATH="$PWD/dist/build/fixpoint:$PATH" or similar should work | 10:34:13 |
|  Uraraka ~ Ochaco joined the room. | 11:41:24 |
 Manuel Bärenz | Redacted or Malformed Event | 12:03:39 |
| Artem | oh 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 | there 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 level | 15:10:01 |
| Artem | I'm guessing the versions are specified in configuration-hackage2nix/main.yml | 15:23:38 |
| Artem | it says "# This is a list of packages with versions from the latest Stackage LTS release." sadly, it doesn't explicitly say if I can add packages outside of LTS in there | 15:24:56 |
| Artem | but the name of its "extra-packages" field suggested that it's the right place | 15:25:47 |
 maralorn | There is stackage.yaml file, which is auto generated. | 15:25:57 |
| Artem | I don't need that one for adding a non-stackage package, right? | 15:26:50 |
| maralorn | Yeah. | 15:27:18 |
| maralorn | Then there is extra-packages which gives additional versioned attributes. | 15:28:14 |
| Artem | my slight worry about configuration-hackage2nix/main.yml#extra-packages is that every package on that list has a comment saying why it's there, and it's very specific. This makes me question that it's the right place. Unless I'm expected to say "# it's a cool package not on Stakage, but I want it in nixpkgs"... | 15:28:24 |
| maralorn | And default-package-overrides which modifies which version the default attribute has. | 15:29:17 |
| Artem | but adding a package not from Stackage is shouldn't overide anything, so this field isn't applicable, right? | 15:31:41 |
