| 5 Dec 2025 |
John Ericson | things like passAsFile and the sturcturedAttrs files get interesting when they contain CA renamings | 22:42:43 |
John Ericson | because can't just pre-generate those files prior to building inputs and make separate store objects | 22:43:08 |
John Ericson | and forgot how to rename them | 22:43:14 |
John Ericson | it is a very annoying problem | 22:43:52 |
| 6 Dec 2025 |
John Ericson | @puck:puck.moe: so edef reminded me that "last minute" input addressing is like merely "applicative" rather than monadic dynamic derivations. This makes me realize that rewriting inputs /placeholders, desugaring structured attrs / passAsFile can be seen as a mini, possibly built-in dynamic derivation | 03:27:50 |
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 |