#“pipeline builder”
summer anchor
New nickname for this: “pipeline builder” 🙂
DX: I now prefer my 2nd option: callbacks. Less weirdness than mandatory pointers, while still allowing that pattern at the developer’s discretion.
I think the problem of “exec vs send” could be solved with an option to the send method: lazy true/false. Perhaps default to false for less surprising (dockerfile-style) result out if the box. power users can set to true.
lean marsh
Well, that’s what I meant by tricky: how would we implement that option. Buildkit is always lazy. Our collective memories are skewed because of Europa: cueflow owned the DAG instead of buildkit, and that’s how we had “lazy=false”
summer anchor
Doesn’t buildkit have a laziness “knob” in solve()?
lean marsh
(when you query the stdout or exitCode field, it’s exporting the layer containing the shim’s output — that’s what unlazies it — not because we decided that that call should not be not lazy)
summer anchor
Yeah that last part is above my pay grade 😅
lean marsh
Doesn’t buildkit have a laziness “knob” in solve()?
There is a knob full of side effects (it becomes “not enough lazy”, kind of). In europa we handled that by controlling everything through flow so that each LLB piece would only be sent once
It’s fuzzy in my head — but that’s why we ended up with #FSID in the CUE tree (too many bugs with #Artifact and attempting to send the same stuff LLB over again with a forced non-laziness)
Anyway — worth digging into, but it’s more than DX, there’s some core changes needed
summer anchor
I have more questions but will keep them for later 😁
lean marsh
DX: I now prefer my 2nd option: callbacks. Less weirdness than mandatory pointer...
For the DX: I don’t know. We’d have to see practical examples. I’m worried it would make control flow harder