Ericson2314
commented
2 years ago @thufschmitt I figured if the way to build hydra against an incremental build is better documented/polished and we do #1166, we wouldn't have to do this huge step :).
I hope that with enough layering and polishing of the layers, there will be in fact less churn in Nix so even if interfaces don't become fully stable, it won't be so bad.
Still, if these other measures do not pan out, yes, monorepo is better than persistent synchronization headaches. Thought it would also require new Nix versions not breaking Hydra (after type errors are fixed, I mean) as is happening today.
Hydra is currently in this very unfortunate situation where it is a different project from Nix, and at the same time very dependent on the internals of Nix. This means that every Nix release will with a pretty high certitude break Hydra one way or another (which will generally only be discovered when someone try to update the Nix input of the flake for some reason), and makes the whole thing some kind of distributed monorepo where code that’s logically very close (there’s no real frontier between the Hydra code and the Nix code, and a big overlap in the developers) physically lives in two different places.
Given the state of things, wouldn’t it make more sense to fully merge the two projects into the same repo (so that any Nix change that breaks hydra requires an immediate fix)?
Alternatively we could fully separate them, but that would require having a somewhat sable Nix interface that Hydra could build onto. Which would be truly awesome, but is a bigger undertaking.
(I suspect this might be a hot topic and I don’t want to start a flamewar, so feel free to close the issue and shut me up if that’s not something to discuss :wink: )