nix-review 1.0 makes package review results inspectable
nix-review 1.0 improves build selection, logs, and reports while preserving the distinction between reviewing a merged result and a standalone branch.
Reviewing a package update requires knowing which packages changed and obtaining results that can be inspected afterwards. The December 3 nix-review 1.0.0 announcement improves both parts. It adds alias deduplication and regular-expression filtering, alongside per-build logs, result symlinks, and Markdown reports. These changes reduce repeated work and make the evidence of a local review easier to examine.
The announcement also says the tool now uses nix build for a progress display and generates Nix expression files. Generating files fixes large rebuilds whose package names were too large to pass directly to nix-shell. That is a concrete scaling problem in the review procedure, independent of whether the individual packages are difficult to compile.
I find tooling like this relevant to declarative infrastructure because changes to package descriptions need evidence about their consequences. A readable expression is part of a review, but it does not establish that the resulting packages build or that a selected result behaves correctly. The tool makes the build-and-inspect part more repeatable.
The tagged release requires Python 3.6 or newer and Nix 2.0 or newer. These requirements describe the review tool itself, separately from the package revisions it checks out or the platforms supported by a selected package.
Evaluation identifies the proposed work
The README at the 1.0.0 tag describes automatic building of packages changed by a Nixpkgs pull request. It can reuse ofBorg evaluation output to identify the rebuild set, avoiding duplicate local evaluation. When that result is unavailable, it falls back to evaluating locally.
That reuse is a specific optimization, with a documented escape route. The README says --eval local is useful when the ofBorg result is outdated. The review still needs an appropriate account of what changed. Reusing an existing evaluation saves work only when it describes the change being reviewed.
Alias deduplication addresses another source of repeated work. More than one package attribute can identify the same build result. Treating every name as an independent build can obscure what the review actually needs to produce. The announcement explicitly identifies detecting and deduplicating those aliases as a new capability.
This distinction also affects how a report should be read. An attribute is a way to select a package in the collection, while the build result is the object produced. A report with many names does not necessarily imply an equal number of independent results. Deduplication makes the review procedure account for that relationship.
The checkout strategy defines the question
By default, the tagged README says nix-review merges the pull request into its target branch for review. That evaluates the proposed change in the context where it is intended to land. The tool detects the target branch and uses Git worktrees for checkouts, so the existing working checkout need not be replaced by the review checkout.
The alternative --checkout commit tests the proposed branch without merging the target branch. The README explains why that can help when unrelated mass-rebuild changes have landed on the target branch but their binaries are not yet available from Hydra. Incorporating those changes could make a local review perform substantial extra work unrelated to the proposed package update.
These strategies establish different facts. The default asks about the combined result at the current target. The commit strategy asks about the branch as it stands. Avoiding unrelated rebuild work can be useful, but a successful standalone branch build does not automatically establish that the merged result behaves identically.
A local commit can also be reviewed without a pull request through nix-review rev HEAD. This extends the same build-oriented procedure to work that has not entered the hosted review process. The README allows a commit or branch in that position, making the selected revision an explicit input to the review.
A selected subset needs a visible scope
The tagged documentation supports selecting individual packages with -p, as well as filtering attribute names through a regular expression. This is useful for large rebuild sets. A reviewer can focus on relevant packages without requiring every affected result to complete before any useful inspection begins.
The scope of the result still matters. Selecting a subset establishes evidence for the selected packages. It should not be reported as proof that the entire affected set succeeded. The tool makes narrowing possible, while the reviewer remains responsible for saying which work the report covers.
NixOS tests can be selected through the nixosTests attribute set using the same package-selection facility. The README gives examples of running a named test and explains that the checkout strategy can avoid an unrelated kernel rebuild. This places system tests within the review workflow without claiming every package review runs every NixOS test.
Remote builders provide another way to execute the work. The documented tool forwards build arguments to the underlying build command. The result can therefore come from a configured remote build arrangement while the local review still manages selection and inspection. Where a build runs and which change it tests are separate choices.
Logs and environments support inspection
The 1.0.0 documentation describes logs for built and failed packages and symlinks to build results. It also supplies a nix-shell containing packages that did not fail. These outputs let a reviewer move from the summary of a build to the actual executable or recorded failure details.
The generated expression files address the command-size problem described in the announcement. They also provide expressions that a user can build directly. The set of selected packages does not have to remain encoded only in one oversized command invocation. That makes the requested build work available in a form the package manager can consume separately.
I prefer review evidence that retains this connection between selection and result. Markdown output helps communicate what happened, while logs and result paths allow inspection beyond the summary. nix-review 1.0 improves those artifacts together with the rules that determine which packages are built, so the report can be related to a specific revision and a stated selection of packages.