Skip to content

Add build options for setting absolute paths to Nix libexec helpers#16110

Open
PhilipTaronQ wants to merge 5 commits into
NixOS:masterfrom
PhilipTaronQ:worktree-shell-out-build-time-configs
Open

Add build options for setting absolute paths to Nix libexec helpers#16110
PhilipTaronQ wants to merge 5 commits into
NixOS:masterfrom
PhilipTaronQ:worktree-shell-out-build-time-configs

Conversation

@PhilipTaronQ

@PhilipTaronQ PhilipTaronQ commented Jul 7, 2026

Copy link
Copy Markdown

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.

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 github-actions Bot added new-cli Relating to the "nix" command fetching Networking with the outside (non-Nix) world, input locking labels 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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why such stark contrast with how git program is handled?

@PhilipTaronQ PhilipTaronQ Jul 7, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

fetching Networking with the outside (non-Nix) world, input locking new-cli Relating to the "nix" command

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants