Remove the build hook mechanism

[edolstra]

Like the substituter mechanism, we can use the Store abstraction instead. I.e. we call remoteStore->buildPaths(...) directly rather than calling an external process that does the same thing.

[expipiplus1]

Would this just be an internal change to Nix? If not, how would this affect those of us who are using NIX_BUILD_HOOK with things other than build-remote.pl?

[edolstra]

It would break your build hook. What are you using NIX_BUILD_HOOK for?

[expipiplus1]

I'm using NIX_BUILD_HOOK with nix-instantiate and nix-store --realise in order to easily get machine readable output of the build in progress. By using a build hook with these tools I can have precise control over what's being built when, and the output of the builder.

It's also been useful in getting some better --dry-run functionality as described here too.

[veprbl]

@expipiplus1
Which entity executes NIX_BUILD_HOOK in your scenario? I'm asking because both nix-build and nix-store -r will try to lock the output path, so you can't have one just call another.

EDIT: seems like NIX_HELD_LOCKS is the mechanism for this, but it is ignored by nix-store -r.

[LisannaAtHome]

Would doing this prevent implementation of use cases like #1914?

[edolstra]

@ledettwy No, it shouldn't affect that.

[edolstra]

@volth You can force a local build by passing --builders ''.

[edolstra]

You're right, it requires a trusted user. We could require the untrusted user's builders to be a subset of the daemons builders though.

[arianvp]

I'm using build hooks to incrementally push things to the cache (as opposed to only after a full derivation built). Is there a better mechanism for doing this?

[arianvp]

Nevermind. I'm using post-build hooks. sorry

[stale]

I marked this as stale due to inactivity. → More info

[stale]

I closed this issue due to inactivity. → More info

[Ericson2314]

I have wondered whether as part of a migration we could have a build-hook:// store too.

[edolstra]

Nix team discussion: The consensus is that we want to get rid of the build hook. There may be some issues around derivation cancellation, but that's not a big problem right now.

As a first step, we could remove the build-hook setting.

[domenkozar]

Is there an alternative? This will break many existing CI setups.

[Ericson2314]

Alternative to which part? Overriding the build hook?

If that is in wide use, then yes we'll have to approach this the other way of doing a remoteBuildersNg (haskellPackagsNg, I remember you!) and then migrating people over to it, and then getting rid of the old build-hook way.

My comment about about a "build-hook:// store" would just serve to de-dup code during the deprecation period.

[L-as]

What is the point in removing it if it's e.g. only 100 lines of code to maintain?

I still do think remote building shouldn't go through the hook, but the hook might still be useful to keep around (for CI, as noted above).

OTOH, wouldn't the C API be a suitable replacement too?