| 15 Sep 2025 |
 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 |
| bglgwyng | I think I can remove the usage of callCabal2nix and it's in the roadmap | 07:22:18 |
| Alex | I guess disabling IFD with --option is one way of being sure. | 07:22:19 |
 MangoIV | it's every time where you have an output and you reflect whatever that output contains back into the evaluation phase | 07:22:48 |
| bglgwyng | I see | 07:24:03 |
| Alex | IFD is far from a show-stopper for most people, but it does mean slower evaluation when e.g. entering nix-shell. | 07:24:04 |
| MangoIV | From a build system theory perspective, the issue is, that while nix normally can do planning statically, because it's (without IFD) an Applicative build system, if you need to build first, you basically get intransparent branching from nix' perspective | 07:24:41 |
| MangoIV | which is funny because the slower evaluation is just an implementation problem, while there are actual theoretical problems with this that are not the problem that people face in practice (e.g. the issue that you cannot usefully distribute to build machines before having a full plan, which requires building all the IFD first) | 07:26:20 |
| bglgwyng | Hmm indeed I started to write nix-x-cabal when I found a small bug(maybe?) in haskell.Nix and also found haskell.Nix is too complicated. | 07:26:48 |
