| 16 Sep 2025 |
 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 |
| bglgwyng | But if I should introduce things like materialization for performance, then | 07:27:07 |
| bglgwyng | it's going to be almost reinventing haskell.Nix then lol | 07:27:18 |
| MangoIV | you're hardly gonna reinvent haskell.nix tbf | 07:27:43 |
| MangoIV | the biggest part of what haskell.nix gives you is the cross machinery | 07:28:00 |
| MangoIV | and that's quite behind in nixpkgs | 07:28:10 |
| Alex |
behind in nixpkgs
Cross works though? What else is missing? | 07:28:53 |
| bglgwyng | Do you think IFD on plan.json be slow? I thought that if plan.json is cached and the evalution of its derviation is fast, then it would be ok. Or, is just every IFD slow then? | 07:33:54 |
| Alex | In reply to @bglgwyng:matrix.org
Do you think IFD on plan.json be slow? I thought that if plan.json is cached and the evalution of its derviation is fast, then it would be ok. Or, is just every IFD slow then? If it's cached it's not a problem.
But often it's not cached, because Nix doesn't know that the store paths produced by IFD depend on the store path being imported.
So any GC deletes the path unless(?) you're in the middle of evaluating it. | 07:35:39 |
| bglgwyng | I'll check it. If I implemented correctly as I intended, then plan.json's rebuild should only depends on *.cabal files and repositories option values, which are not changed often. | 07:37:07 |
| MangoIV | I think haskell.nix can do Windows cross, I wasn't aware nixpkgs can do that | 07:37:35 |
| Alex | In reply to @mangoiv.:matrix.org
I think haskell.nix can do Windows cross, I wasn't aware nixpkgs can do that True, Windows support should not be expected in Nixpkgs in general. | 07:38:21 |
 sterni (he/him) | In reply to @bglgwyng:matrix.org
Do you mean a bug in builtins.functionArgs? haskellPackages.mkDerivation | 09:49:44 |
| sterni (he/him) | or rather the callPackage implementation | 09:49:59 |
| bglgwyng | Yes. I realized that after I tried to fix the issue. | 09:54:08 |
| bglgwyng | I think that callCabal2Nix result would better expose expr of itself as an attribute. | 09:54:40 |
