From 2f954e3e84695157da6e68fbeb7bb77c6b8a1f83 Mon Sep 17 00:00:00 2001 From: John Ericson Date: Fri, 9 Aug 2024 11:32:26 -0400 Subject: [PATCH] Apply suggestions from code review Co-authored-by: Robert Hensing --- doc/manual/rl-next/build-hook-default.md | 11 ++++++----- src/libcmd/repl.hh | 2 +- 2 files changed, 7 insertions(+), 6 deletions(-) diff --git a/doc/manual/rl-next/build-hook-default.md b/doc/manual/rl-next/build-hook-default.md index a1b726bb2edc..cace7eefcddc 100644 --- a/doc/manual/rl-next/build-hook-default.md +++ b/doc/manual/rl-next/build-hook-default.md @@ -1,16 +1,17 @@ --- -synopsis: The "build-hook" setting" default is less useful when using `libnixstore` as a library +synopsis: |- + The `build-hook` setting's default is less useful when using `libnixstore` as a library prs: - 11178 --- -*This is an obscure issue just affecting uses of `libnixstore` the library outside of the Nix executable.* +*This is an obscure issue that only affects usage of the `libnixstore` library outside of the Nix executable.* As part the ongoing [rewrite of the build system](https://github.com/NixOS/nix/issues/2503) to use [Meson](https://mesonbuild.com/), we are also switching to packaging individual Nix components separately (and building them in separate derivations). This means that when building `libnixstore` we do not know where the Nix binaries will be installed --- `libnixstore` doesn't know about downstream consumers like the Nix binaries at all. -This has a small adverse affect on remote building --- the `build-remote` executable that is specified from the `build-hook` setting will not be gotten from the (presumed) installation location, but instead looked up on the `PATH`. -This means that other applications linking `libnixstore` that wish to use remote building must arrange for the `nix` command to be on the PATH (or manually overriding the setting) in order for that to work. +This has a small adverse affect on remote building --- the `build-remote` executable that is specified from the [`build-hook`](@docroot@/command-ref/conf-file.md#conf-build-hook) setting will not be gotten from the (presumed) installation location, but instead looked up on the `PATH`. +This means that other applications linking `libnixstore` that wish to use remote building must arrange for the `nix` command to be on the PATH (or manually overriding `build-hook`) in order for that to work. Long term we don't envision this being a downside, because we plan to [get rid of `build-remote` and the build hook setting entirely](https://github.com/NixOS/nix/issues/1221). There is simply no need to add a second layer of remote-procedure-calling when we want to connect to a remote builder. -When the build hook protocol did in principle support custom ways of remote building, that can also be accomplished with a customer service for the ssh or daemon/ssh-ng protocols, or with a custom store class. +The build hook protocol did in principle support custom ways of remote building, but that can also be accomplished with a custom service for the ssh or daemon/ssh-ng protocols, or with a custom [store type](@docroot@/store/types/) i.e. `Store` subclass. diff --git a/src/libcmd/repl.hh b/src/libcmd/repl.hh index cdf27af0b284..11d1820f504b 100644 --- a/src/libcmd/repl.hh +++ b/src/libcmd/repl.hh @@ -23,7 +23,7 @@ struct AbstractNixRepl /** * @param runNix Function to run the nix CLI to support various - * `:` commands. Can not be provided, in which case + * `:` commands. Optional; if not provided, * everything else will still work fine, but those commands won't. */ static std::unique_ptr create(