| 6 Apr 2026 |
 sterni | the thing is that there can't really be a generic solution for everything because there are a lot of mutually incompatible approaches to solving this at the moment. | 11:34:22 |
 alexfmpe | Sure, but we can have a ready made sane default | 11:34:50 |
| sterni | w.r.t. your specific question if you look at the GHC_PACKAGE_PATH stuff, we have a way of preventing our wrapper from setting that if you need cabal. But i expect it'll break in a different way then. | 11:35:18 |
| sterni | if someone has a lot of spare time they could investigate making an opt in alternative generic-builder.nix code path that uses cabal-install which could have some advantages | 11:36:17 |
| alexfmpe | I suspect stack also doesn't set it. First saw this when packaging haskell-debugger and IIRC stack test also got tripped up, only cabal test was green | 11:36:57 |
| sterni | cabal sets GHC_ENVIRONMENT which is annoying to replicate manually unfortunately. | 11:37:26 |
| sterni | but it also doesn't do everything for some use cases you need to run cabal v2-exec -- cabal v2-test (i think path being set) | 11:37:52 |
| alexfmpe | In reply to @sternenseemann:systemli.org
if someone has a lot of spare time they could investigate making an opt in alternative generic-builder.nix code path that uses cabal-install which could have some advantages That's huh, big. Right now I'm only trying to fix a couple packages without excessive copy pasting | 11:38:01 |
| sterni | don't worry about it, I don't think it solves much we are facing right now. cabal-install also has plenty of problems. | 11:39:18 |
| sterni | i just feel like it may be wise long term since every solution for rough spots in cabal nowadays get designed around cabal-install v2-commands and they are often implemented poorly in Setup.hs to the degree that they are outright broken e.g. https://github.com/haskell/cabal/issues/11598 | 11:40:37 |
| sterni | (the build-tool-depends thing btw si another example for a stupid hack packages use to get the executable into PATH for the test suite) | 11:41:00 |
| alexfmpe | I do think it's worth looking into at some point down the line, just have a bunch of other cabal2nix/haskellPackages stuff on my queue already | 11:57:27 |
| 9 Apr 2026 |
|  eliasp joined the room. | 14:13:34 |
| eliasp | Hi
I have very little knowledge when it comes to the general Haskell ecosystem/build process etc - I'm struggling with applying a custom patch via haskell.lib.compose.appendPatch to a package (hledger).
It fails applying the patch, complaining it can't find the file targeted in the patch…
> applying patch /nix/store/s3f1dgvk0ddzp87sg9j2npb7j7avdanw-imp-add-continue-rule-for-CSV-import.patch
> can't find file to patch at input line 3
> Perhaps you used the wrong -p or --strip option?
> The text leading up to this was:
> --------------------------
> |--- a/hledger-lib/Hledger/Read/RulesReader.hs
> |+++ b/hledger-lib/Hledger/Read/RulesReader.hs
> --------------------------
> File to patch:
> Skip this patch? [y]
> Skipping patch.
Do I need to do anything special to apply patches to Haskell packages? Couldn't find anything relevant to my problem in the docs. | 14:18:02 |
| eliasp | Oh, nvm - just realized I'm being stupid and should apply the patch to hledger-lib instead of hledger 🤦 | 14:19:14 |
| sterni | you also need to use the relative argument of fetchpatch so the paths are correct | 15:28:12 |
| 10 Apr 2026 |
|  @epimonic:matrix.org left the room. | 11:46:02 |
| 11 Apr 2026 |
| alexfmpe | do we propagate buildToolDepends, testToolDepends, etc?
I'm experimenting with allowing doCheck via canExecute (e.g. pkgsStatic) and running into a lot of things missing hspec-discover | 23:06:33 |
| alexfmpe | somehow it builds fine on native | 23:06:40 |
| alexfmpe | I'm also wondering whether addTestToolDepend self.buildHaskellPackages.hspec-discover is what we should always do
or if there's a point to this (commented) conditional:
https://github.com/NixOS/nixpkgs/blob/86ab6aea5099ecae02ef2331cfd3f1d53362f1db/pkgs/development/haskell-modules/configuration-common.nix#L1209 | 23:07:57 |
| 12 Apr 2026 |
| sterni | I don’t think so. do you have some examples? I have a suspicion, but would need to check. | 07:41:57 |
|  leona changed their profile picture. | 12:15:40 |
| alexfmpe | all of these build on haskellPackages but need that override on pkgsStatic.haskellPackages
https://github.com/alexfmpe/nixpkgs/blob/27752ed2109458fdc93a0917123f9566920c13e6/pkgs/development/haskell-modules/configuration-nix.nix#L2271-L2287 | 13:28:44 |
| alexfmpe | $ nix-shell default.nix -A haskellPackages.say --run 'hspec-discover'
Usage: hspec-discover SRC CUR DST [--module-name=NAME]
$ nix-shell default.nix -A pkgsStatic.haskellPackages.say --run 'hspec-discover'
/tmp/nix-shell-3496921-3747326576/rc: line 3: hspec-discover: command not found
| 13:31:18 |
| sterni | A the answer is likely that these packages depend on hspec which depends (not build-tool-depends!) on hspec-discover which gets propagated and is executable when natively compiling | 21:07:24 |
| sterni | e.g. say has the packaging bug that it doesn't declare the dependency at all, should be using build-tool-depends. | 21:07:48 |
| sterni | we have a hack in cabal2nix that fixes if you use build-depends : hpsec-discover, but if you don't declare the dep at all, it's problematic of course | 21:08:13 |
| alexfmpe | Ah, guess the hack hid the problem | 21:52:17 |
| alexfmpe | So the fix here is to PR those addFooToolDepends unconditionally yeah? | 21:52:39 |
| alexfmpe | (well, the non-upstream fix) | 21:53:42 |
