| 6 Dec 2025 |
 John Ericson | I think this works nicely with the core derivation only having input sources, and being what is given to the builder | 03:28:45 |
| John Ericson | Put another way, depending on an unbuilt derivation output is more domain-specific operation | 03:29:18 |
| John Ericson | The graph can be full of domain-specific garbage because the sandboxer doesn't care | 03:29:47 |
 puck | passAsFile/etc are kinda wonky; i'd at best consider this a separate .drv format, really
the original design i lost was like. a {* str => user-defined-format} so you could have {"nix.drv.v1": {...}} and have those serve as, basically, the way requiredSystemFeatures is abused | 09:43:23 |
| puck | and yeah, i realise i can actually slim down the core data a bit more; the map of derivation inputs can live in the meta/steering data entirely (because the bstr in the steering data is enough to verify the store path) though it makes rewriting derivations a bit wonkier | 09:44:37 |
| puck | but CA derivations would have to be represented as a slightly different format to make the realisation format Sensible with this | 09:45:09 |
| John Ericson | @puck:puck.moe: yeah sounds good. We have enough legacy cruft that I sort of like to let the refactoring "organically" figure out the details, if that makes sense | 16:29:57 |
| John Ericson | For example, on the observation that the core derivation format corresponds to what the builder/sandboxer needs, I would keep on trying to clean up that interface until CoreDerivation emerges organically | 16:30:43 |
| John Ericson | And then I would try to have the "build trace" use core derivations as much as possible | 16:31:27 |
| John Ericson | Because it increases cache hits | 16:31:37 |
| John Ericson | (though at the cost of making looker-uppers do a bit more work before they have the cache key to check) | 16:32:23 |
| John Ericson | An example of this sort of refactoring is that DerivationBuilder doesn't know about inputsDrvs (good!) but it does know about DerivationInput and all of DerivationOptions (maybe not so good!) | 16:33:58 |
| John Ericson | registerOutputs in general is way too full of policy knobs | 16:34:27 |
