[Nix#2236] Treat remote builders as substituters? #141

New issue

Open

opened 2024-03-16 06:45:08 +00:00 by lix-bot · 0 comments

lix-bot commented

2024-03-16 06:45:08 +00:00

Member

Upstream-Issue: NixOS/nix#2236

I can see some potential advantages to treating remote builders as substituters before trying to build any derivations — this would allow the build plan to be executed more efficiently in some cases, with less copying around of paths and potentially less overall building as well.

Consider:

b.drv, a derivation which produces the output path /nix/store/b
c.drv, a derivation which produces the output path /nix/store/c
a.drv, which produces the output /nix/store/a and depends on the outputs of b.drv and c.drv. /nix/store/a has a reference to /nix/store/b but none to /nix/store/c.
Build initiator alice, having bob and charlotte configured as remote builders, doesn't have any of the output paths available, nor can it build any of the drvs (incompatible system or something)
Builder bob doesn't have any of the paths available, but can build them
Builder charlotte has all the paths built.

Now running nix build /nix/store/a.drv on alice can result in something like the following:

alice makes bob build b.drv and copies the output path over
alice makes charlotte build c.drv (no-op) and copies the output path over
alice copies /nix/store/c to bob and makes bob build a.drv, then copies the output path over

End result being that all three derivation's output paths have been copied to all three systems, and b.drv and a.drv have been unnecessarily rebuilt.

If alice has bob and charlotte configured as substituters additionally, alice will first query them for /nix/store/a, and upon determining that charlotte already has the path, will only copy /nix/store/a and /nix/store/b to itself, resulting in no unnecessary building and no superfluous space usage.

Are there any drawbacks to universally treating builders as (absolutely trusted, i.e. no sigs required) substituters as well?

Upstream-Issue: https://git.lix.systems/NixOS/nix/issues/2236 I can see some potential advantages to treating remote builders as substituters before trying to build any derivations — this would allow the build plan to be executed more efficiently in some cases, with less copying around of paths and potentially less overall building as well. Consider: - `b.drv`, a derivation which produces the output path `/nix/store/b` - `c.drv`, a derivation which produces the output path `/nix/store/c` - `a.drv`, which produces the output `/nix/store/a` and depends on the outputs of `b.drv` and `c.drv`. `/nix/store/a` has a reference to `/nix/store/b` but none to `/nix/store/c`. - Build initiator `alice`, having `bob` and `charlotte` configured as remote builders, doesn't have any of the output paths available, nor can it build any of the drvs (incompatible system or something) - Builder `bob` doesn't have any of the paths available, but can build them - Builder `charlotte` has all the paths built. Now running `nix build /nix/store/a.drv` on `alice` can result in something like the following: - `alice` makes `bob` build `b.drv` and copies the output path over - `alice` makes `charlotte` build `c.drv` (no-op) and copies the output path over - `alice` copies `/nix/store/c` to `bob` and makes `bob` build `a.drv`, then copies the output path over End result being that all three derivation's output paths have been copied to all three systems, and `b.drv` and `a.drv` have been unnecessarily rebuilt. If `alice` has `bob` and `charlotte` configured as substituters additionally, `alice` will first query them for `/nix/store/a`, and upon determining that `charlotte` already has the path, will only copy `/nix/store/a` and `/nix/store/b` to itself, resulting in no unnecessary building and no superfluous space usage. Are there any drawbacks to universally treating builders as (absolutely trusted, i.e. no sigs required) substituters as well?