| 5 Dec 2025 |
 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 |
| John Ericson | It reeks of "configuration not composition" | 16:34:47 |
 jade_ | raitobezarius: fyi there's internal server errors on zulip.lix.systems when trying to log in | 19:52:38 |
 raitobezarius | fixed, that's due to a keycloak breaking change | 19:53:10 |
| jade_ | ty | 19:53:46 |
| raitobezarius | https://cl.afnix.fr/c/infra/+/175 | 19:53:54 |
 Winter | raitobezarius are you aware of similar issues when logging into forgejo? this has been happening for months though but just curious if you’re aware | 20:03:49 |
| jade_ | is this 100% reproducible or inconsistent? | 20:04:15 |
| raitobezarius | not-100% reproducible | 20:04:21 |
