| 5 Dec 2025 |
 Zoe Z | did this get a backport to 2.94? | 16:56:58 |
 raitobezarius | https://gerrit.lix.systems/c/lix/+/4706 cp now open | 16:58:36 |
| Zoe Z | thanks | 17:00:11 |
|  👉@crystallinefire:chat.solarpunk.moe changed their display name from EVA-01 to 👉@crystallinefire:chat.solarpunk.moe. | 17:17:33 |
| Zoe Z | not sure if I count as a valid reviewer on a backport of my own change, but I +1'd it anyway | 17:21:06 |
 Qyriad | imho yes, the original author is a great reviewer for a backport of their coded | 18:53:54 |
| Qyriad | * imho yes, the original author is a great reviewer for a backport of their code | 18:54:01 |
| Zoe Z | still getting used to gerrit | 20:41:49 |
 puck | hi i am very functional https://docs.puck.moe/docs/4296f585-7f32-4f63-b4da-ea2038a7fd99/ | 21:51:17 |
 John Ericson | puck: what is in output? | 22:40:56 |
| John Ericson | just the name? | 22:41:00 |
| puck | the name, and probably the shape of output (so CA renamings where applicable, tho i solved this by just not doing it in the daemon) | 22:41:48 |
| 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 |
| 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 |
