| 20 Dec 2025 |
 piegames | In reply to @522_:catgirl.cloud
i don't think npins strictly speaking uses ifd, it just uses builtins fetchers? IMO builtin fetchers are no different than IFD for all intents and purposes | 13:04:47 |
| piegames | My dream is to have builtin fetchers return a special derivation which would make the IDF part more explicit (and also be part of an IFD as first-class citizen approach) | 13:05:33 |
| piegames | But tbh that is not my battle field to work on, so other people may decide differently | 13:06:11 |
 0x4fbb09 it/its ⛯✇ΘΔ | ig you could vendor "nixpkgs but just enough to make fetchers work" and then use those fetchers for everything else | 13:06:37 |
| 0x4fbb09 it/its ⛯✇ΘΔ | so you're not vendoring All Of Nixpkgs but also not using builtin fetchers | 13:06:53 |
 kloenk | would that help anything? does still need IFD then, or am I missing something right now? | 13:08:21 |
| 0x4fbb09 it/its ⛯✇ΘΔ | uhhhh maybe, but it wouldn't block eval on a network download ig? | 13:08:46 |
| 0x4fbb09 it/its ⛯✇ΘΔ | well actually no if it's just vendored then it's just like any other code in your project | 13:09:20 |
 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 |
