Reusing Failed Cargo Builds

[nz366]

process-temp seems to be filled with duplicates each time brioche run is called. I have not found any option to reuse the previous process so cargo just compiles remaining files not the whole dependency tree each time?

[kylewlacy]

So, a few different things to unpack here!

• Each time we build a recipe, we run in a fresh sandbox starting from a clean slate. This is by design to keep the builds reliable. There's some philosophy on the "Sandboxing" docs page (and this is in-line with how other build tools work, like Nix and Bazel).
• The cargoBuild() function is kinda naive today, and just uses a single recipe for the main build step. Since it's just one recipe, if any part of it fails, the whole thing fails and we'll have to start from scratch
• Technically, the cargoBuild() function could be re-written, so each crate gets compiled separately. I think this is basically how cargo2nix works. But, this is a lot of work! It'd mean basically implementing part of what Cargo does directly in TypeScript
• Once Spawn recipes within recipes (sccache-like builds) #343 is implemented, we could get the best of both worlds. That would let us use Cargo still, but still split compilation into multiple recipes, somewhat similar to using sccache
• ...I've also had the idea to let a recipe directly re-use a special cache directory between build steps, although this would need to be opt-in and would be a little dangerous! But that could let us use compilation tools with their own incremental compilation in a structured way. This is still a pretty fuzzy idea though
• For day-to-day development, this is where dev shells could come in (Add support for dev shells #162). Rather than doing the build in Brioche itself, you could install Cargo through Brioche (scoped to the current project), then just use Cargo normally to do the build. That way, Cargo would be working with your normal target/ dir and could manage the build entirely itself. In this case, Brioche could either be used to make the release build reliable and/or reproducible, or even just to provide a pinned version of Cargo between devs and the CI system, or some other mix

[nz366]

• Each time we build a recipe, we run in a fresh sandbox starting from a clean slate. This is by design to keep the builds reliable. There's some philosophy on the "Sandboxing" docs page (and this is in-line with how other build tools work, like Nix and Bazel).
• The cargoBuild() function is kinda naive today, and just uses a single recipe for the main build step. Since it's just one recipe, if any part of it fails, the whole thing fails and we'll have to start from scratch

I think it's important to have clean builds. For the time being I assume brioche could have a flag --reuse-temp to simply symlink previous data to the new one and cargo would handle it normally?

[kylewlacy]

So, for a --reuse-temp feature, just finding the previous failed build dir is pretty tricky! Each time we build a recipe, we create a new directory with a random name. And since multiple builds can run in parallel, there might not even be a single previous failed build dir. The recipe hash doesn't help us, since if any of the inputs to the recipe change at all-- say, updating the source code in the project, or basically any change you could try to make to fix a build-- then the recipe hash changes, and there's no concept to get what the "previous" recipe hash was. It's just impossible to do with the way recipes are structured today¹.

There are several other challenges (although not as big), and there are some extra core features we'd need beforehand too. But point is, I feel like this feature sounds pretty easy to implement, but it's actually pretty hard and there are a lot of technical hurdles on the way!

I'm not opposed to supporting a feature like this (it's not "pure", but I'm more interested in pragmatism over purity). I think some of the things I listed above are lower-hanging fruit, and so I'd be much more in favor of tackling some of those features first, then re-addressing a --reuse-temp flag if there are places where it's would still be helpful

Footnotes

1. ...well, I could think of some heuristics, like searching for the last failed recipe that came from the same .bri file at the same line number or something. But Brioche is content-addressed, so there's just no "native" concept of what a previous recipe is, and so it'll always be a fuzzy solution... ↩

[nz366]

• For day-to-day development, this is where dev shells could come in (Add support for dev shells #162). Rather than doing the build in Brioche itself, you could install Cargo through Brioche (scoped to the current project), then just use Cargo normally to do the build. That way, Cargo would be working with your normal target/ dir and could manage the build entirely itself. In this case, Brioche could either be used to make the release build reliable and/or reproducible, or even just to provide a pinned version of Cargo between devs and the CI system, or some other mix

Cant wait for dev shells. What is blocking this feature?

[kylewlacy]

I don't think there's anything blocking this work today! The design's still a little fuzzy, so there's some exploration on how best to implement it, but beyond that it's just a matter of priority with other issues / interest in contributing it