| 16 Sep 2025 |
 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 |
