| 16 Sep 2025 |
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 |
@wolfgangwalther:matrix.org | 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 |