Add build options for setting absolute paths to Nix libexec helpers#16110
Open
PhilipTaronQ wants to merge 5 commits into
Open
Add build options for setting absolute paths to Nix libexec helpers#16110PhilipTaronQ wants to merge 5 commits into
PhilipTaronQ wants to merge 5 commits into
Conversation
I added a new meson option `libfetchers:git-program` (default: `"git"`) which is threaded through all six `git` exec sites in `git.cc`/`git-utils.cc` via a generated `GIT_PROGRAM`, plus a public `gitProgram()` accessor used by the flake commit-lock-file path in `src/nix/flake.cc`. The binary named by this option is either resolved via PATH or an absolute path. Since the default is "git", today's behavior remains the default if this commit is merged. Motivation: distributions that bundle a known-good git (such as a macOS standalone package) need Nix to invoke it by absolute path instead of trusting PATH at run time. Assisted-by: Claude Code (Claude Opus 4.8)
…cher) I added a new meson option `libfetchers:mercurial-fetcher` (default: `true`). When disabled (via generated `ENABLE_MERCURIAL`), hg inputs fail with an explicit 'Mercurial support is not included in this build of Nix' at input recognition. This applies to both both `hg+` URLs and `type=hg` attrs. I felt this was much preferable to a confusing exec failure at fetch time.
I added a new meson option `libstore:ssh-program` (default: `"ssh"`) threaded through SSHMaster's two exec sites via a generated `SSH_PROGRAM`. This is either a name resolved via PATH or an absolute path. Since the default is `"ssh"`, today's behavior persists. Motivation: distributions that bundle a known-good ssh need Nix to invoke it by absolute path instead of trusting PATH at run time. Assisted-by: Claude Code (Claude Opus 4.8)
I added a new meson option `libstore:lsof-program` (default: empty).
Empty keeps today's behavior. If it's empty, meson at build-time uses `find_program('lsof')` to find `lsof`, with a run-time PATH fallback.
On the other hand, a non-empty value for `libstore:lsof-program`` pins the `lsof` used by the garbage collector to find runtime roots.
We could likely do this better, but this works well enough for my purposes.
Assisted-by: Claude Code (Claude Opus 4.8)
I added a new meson option `nix:bash-program` (default: `"bash"`) threaded through the `interactive-shell` fallback in `nix develop` and `nix-shell` via a generated `FALLBACK_BASH` This is the shell used when bashInteractive from nixpkgs is unavailable. It's either a name resolved via PATH or an absolute path; since the default is "bash", today's behavior remains when this patch is merged. Motivation: distributions that bundle a known-good bash need Nix to invoke it by absolute path instead of trusting PATH at run time. Assisted-by: Claude Code (Claude Opus 4.8)
github-actions
Bot
added
new-cli
xokdvium
reviewed
Jul 7, 2026
Comment on lines
+52
to
+55
| #if !ENABLE_MERCURIAL | ||
| throw Error( | ||
| "cannot fetch '%s': Mercurial support is not included in this build of Nix", url.to_string()); | ||
| #endif |
Contributor
There was a problem hiding this comment.
Why such stark contrast with how git program is handled?
Author
There was a problem hiding this comment.
Mostly because I was scared of packaging Mercurial for use with Nix. I can separate out this build flag if you think that the others are uncontroversial.
Contributor
There was a problem hiding this comment.
I mean, disabling the support outright might not be exactly how we try to handle this stuff (i.e. just looking up in PATH by default). Not sure about the inconsistency here. Maybe just don't do anything for mercurial just yet and leave the status quo without an explicit option to disable it? If it's not in the PATH then it's not in the path.
Author
There was a problem hiding this comment.
I'll drop the patch and apply one that's like the others.
xokdvium
reviewed
Jul 16, 2026
Comment on lines
-269
to
-273
| configdata_priv.set_quoted( | ||
| 'LSOF', | ||
| lsof.found() ? lsof.full_path() | ||
| # Just look up on the PATH | ||
| : 'lsof', |
Contributor
There was a problem hiding this comment.
Oh god why did we use to do it this way? Hardcoding a path from the build environment doesn't seem great.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
Nix uses several binaries to do its work.
git.bash.hg.lsof.ssh. I'd like to bundle a known-good version of these tools, and bake that path into the binary, and I didn't have a tool other than patching Nix for doing so.Context
I'm looking to build stand-alone Nix which doesn't depend on the Nix store, but also doesn't just use whatever tools are in the path. That takes some discernment.
AI disclosure
I used Claude to help find the right incantations for Meson.
Add 👍 to pull requests you find important.
The Nix maintainer team uses a GitHub project board to schedule and track reviews.