| 15 Sep 2025 |
 bglgwyng | Ah I see | 16:06:43 |
| bglgwyng | Thanks! | 16:06:46 |
| bglgwyng | One thing annoying is that I can investigate the argments with builtins.functionArgs (pkgs.callCabal2nix name src) | 16:13:54 |
| bglgwyng | Maybe it's because wrapped? I think I can find how to fix it | 16:14:12 |
 keypusher | So going the addBuildTools route will require me to build wo using callCabal2Nix then? | 16:19:31 |
 maralorn | I am missing a bit of context, but I don’t think so. Both functions are compatible. First call callCabal2Nix then apply addBuildTools to the result of the function. | 16:33:23 |
| keypusher | Oh ok. I'll try that | 16:34:22 |
| keypusher | You made my day. 4 hours of struggling just came to an end. My nix intuition is lacking. | 16:36:43 |
| keypusher | Thanks 🎉 | 16:37:15 |
 sterni | I noticed that, too, yesterday, I think this is a bug and is probably fixable | 17:43:17 |
 Alex | In reply to @sternenseemann:systemli.org
I would just start with adding a MicroHs package set built with GHC as we don't have hugs and then just iterate on that; maybe add hugs separately, have a hugs package set (if that even makes sense). Not sure which branch to PR to.
I assume haskell-updates is the best choice?
(Hugs fix without GCC 13 is ready.) | 22:37:00 |
| sterni | can also be master if you don’t depend on anything in h-u | 22:47:03 |
| Alex | Even for the mhs package set? | 22:48:00 |
| Alex | In reply to @sternenseemann:systemli.org
can also be master if you don’t depend on anything in h-u Hugs fix: https://github.com/NixOS/nixpkgs/pull/443281 | 22:53:44 |
| sterni | the mhs package set is probably better on h-u since we’d want to figure out CI | 22:58:06 |
| sterni | I’ll just see to it that hugs gets propagated quickly to the branch after megre | 22:58:29 |
| Alex | Ok, thanks. | 22:58:50 |
| 16 Sep 2025 |
| bglgwyng | Do you mean a bug in builtins.functionArgs? | 00:08:45 |
| bglgwyng | https://github.com/bglgwyng/nix-x-cabal
I wrote another Nix + Haskell framework. It is based on flake-parts and uses plan.json to reproducible builds. It delegates all the network access from Cabal to Nix, and runs cabal build in pure way. | 04:59:21 |
| bglgwyng | It doesn't use pre-baked package set, but resolves version constraints. So you can freely choose any version of ghc(at this moment, in nixpgks.haskell.packages.ghc***) | 05:00:45 |
| bglgwyng | I wish I could provide the docs right now, but nix-options-doc and flake-parts don't play well together for some reasons.. | 05:10:06 |
| Alex | In reply to @bglgwyng:matrix.org
https://github.com/bglgwyng/nix-x-cabal
I wrote another Nix + Haskell framework. It is based on flake-parts and uses plan.json to reproducible builds. It delegates all the network access from Cabal to Nix, and runs cabal build in pure way. Do you have a typo here?
https://github.com/bglgwyng/nix-x-cabal/blob/4c7136218ba15da9304a054fbaeb8641db5592c3/lib/make-noindex-repository.nix#L4
(Was looking through wondering whether you're using IFD.) | 07:17:46 |
| bglgwyng | Thanks! | 07:19:13 |
| bglgwyng | No I don't use IFD | 07:19:16 |
| Alex | Are you sure? It looks to me like you do...
https://github.com/bglgwyng/nix-x-cabal/blob/4c7136218ba15da9304a054fbaeb8641db5592c3/modules/cabal-project.nix#L118
Or maybe I am mistaken and using builtins.readFile on an output is not IFD? | 07:20:28 |
| bglgwyng | ah... callCabal2Nix might use IFD internally | 07:20:35 |
| Alex | In reply to @bglgwyng:matrix.org
ah... callCabal2Nix might use IFD internally That does too IIRC. | 07:20:51 |
| bglgwyng | Is readJSON (readFile ...) also considred IFD? | 07:21:10 |
| bglgwyng | I thought that import in IFD means the usage of `import' keyword | 07:21:40 |
 Wolfgang Walther | If the file is an output of another derivation, then yes. See https://nix.dev/manual/nix/2.30/language/import-from-derivation. | 07:22:08 |
