| 20 Dec 2025 |
 K900 | I want zeroth class IFD | 13:09:23 |
| K900 | I want IFD to just be part of the build graph and no one gives a fuck | 13:09:32 |
 Lotte (it/its)/Cinny (she/her) | yeah | 13:10:14 |
 0x4fbb09 it/its ⛯✇ΘΔ | i assume "ifd is slow" isn't fundmental to the concept and is just an implementation thing | 13:10:33 |
| Lotte (it/its)/Cinny (she/her) | yeah | 13:10:47 |
| Lotte (it/its)/Cinny (she/her) | or racconfig uses IFDs to patch inputs | 13:10:55 |
| Lotte (it/its)/Cinny (she/her) | it also used to use them to generate a stylix palette? | 13:11:11 |
| K900 | IFD is only slow because it blocks everything else | 13:13:03 |
| K900 | Which it absolutely does not have to do | 13:13:07 |
 piegames | You remind me of https://bartoszmilewski.com/2014/02/26/c17-i-see-a-monad-in-your-future/ :p | 13:54:32 |
 pentane ⭔ | yeah I've also already thought about how to model the evaluation/build process of Nix derivarions as a monadic data structure
basically you wanna have a monad like Derivation a, where a is the type of the value produced by the build of the derivation (currently, Nix derivations always produce files or directories, but theoretically nothing speaks against derivations producing strings, integers, etc as their build result too)
Derivation FileOrDirectory would then be equivalent to our current .drv files
| 14:21:10 |
| pentane ⭔ | and the monadic bind operation would correspond to IFD | 14:21:47 |
| pentane ⭔ | cause if you e.g. have a derivation returning a lock file by reading it from an archive or something (Derivation LockFile) and a build helper constructing a package out of that lock file (LockFile -> Derivation Package), you can use >>= to get a Derivation Package | 14:24:26 |
| pentane ⭔ | and the monoid operation join :: Derivation Derivation a -> Derivation a would basically be "build this .drv file to obtain another .drv file and build that in turn, and then return the result` | 14:25:53 |
| pentane ⭔ | although afaict from a theoretical standpoint, this matches the semantics of dynamic derivations better than IFD | 14:26:52 |
| piegames | now that you say all of this, maybe k900 has a point :p | 14:27:06 |
| pentane ⭔ | yeah I also agree with K900 | 14:27:51 |
| pentane ⭔ | another missing puzzle piece imo: currently, Nix treats the eval process and the build process as two conceptually separate things. But afaict there's nothing stopping us from treating the evaluation of, say, a flake as a derivation too - that derivation would have the flake source, its dependencies and nix as inputs, and output a .drv file | 14:30:22 |
| pentane ⭔ | once you've got it set up that way, IFD and dynamic derivations basically are the same thing | 14:31:10 |
| pentane ⭔ | and you get expression language agnosticism for free, since you can then use everything that produces .drv files as an expression language for Nix and not just Nixlang | 14:31:59 |
| pentane ⭔ | thank you for coming to my ted talk | 14:32:04 |
| piegames | Basically from the eval side of things this will be a form of async, where eval halts when it needs the result of a derivation and proceeds once that derivation is built, comparable to waiting for IO | 14:33:01 |
| piegames | TIL nix-build <nixpkgs> works even without --expr for some reason | 14:53:07 |
| K900 | Attrset build target nonsense? | 14:53:39 |
| K900 | Which is a thing you may actually want | 14:58:12 |
| piegames | yes but | 15:02:40 |
 Acid Bong | In reply to @piegames:flausch.social
TIL nix-build <nixpkgs> works even without --expr for some reason because resolves into a filepath entry from NIX_PATH named abc
same thing as nix-build src/nixpkgs | 15:40:18 |
| Acid Bong | * because `<abc>` resolves into a filepath entry from NIX_PATH named abc
same thing as `nix-build src/nixpkgs`
| 15:40:52 |
| piegames | yes I understand that | 15:49:14 |
| piegames | but I find this "fileish" thing weird | 15:49:53 |
