Nix 2.33 exposes registry resolution without fetching a flake
The new registry resolve command shows the direct reference behind an indirect name without fetching source. Broader flake cloning support separates that lookup from obtaining a local source tree.
An indirect flake name is a lookup request, not a complete account of the source it identifies. Before using that source, it is useful to see where the name resolves without fetching it. Nix 2.33 adds nix registry resolve for that purpose and expands nix flake clone to support arbitrary input types.
The December 9 release notes show the registry command resolving nixpkgs to a GitHub reference. They also identify tarball flakes, including those published through FlakeHub, as a newly supported cloning case. Both changes make distinct parts of source handling accessible through direct commands.
I use Nix because explicit inputs make system configuration understandable. An indirect name can still be convenient, provided the lookup is inspectable. This release supplies a command for asking that question without coupling it to a build or an immediate source download.
Resolution produces a direct reference
The versioned command documentation says nix registry resolve consults the available flag, user, system, and global registries. It returns the resolved direct reference on standard output, one line per requested reference. It does not fetch any flakes.
A basic invocation is therefore a lookup diagnostic.
nix registry resolve nixpkgs
The release notes give github:NixOS/nixpkgs/nixpkgs-unstable as an example answer. That example should not become an unconditional prediction for every machine. The command's purpose is to report the answer under the registries actually available to that invocation.
The documentation permits several names in one call. It also describes branch overrides on indirect references, showing nixpkgs/25.05 resolving to the corresponding direct GitHub reference. The lookup can apply multiple redirections until it reaches a direct reference. An unresolved indirect name produces an error.
This means the result is more informative than simply listing an entry whose target might itself require another lookup. The command follows the resolution process to a direct flake reference. Its no-fetch behavior keeps the operation focused on naming and registry configuration.
A direct reference is not necessarily a locked revision
The example result still names a branch. Resolving an indirect name to that direct reference identifies the source location and selector, but it does not by itself turn the selector into an immutable revision. The distinction is visible in the output itself, which contains a branch name rather than a commit identifier.
That matters when describing reproducibility. Registry resolution answers what a shorthand means in the current registry context. Locking an input records a selected source state for the dependency graph. A command that deliberately does not fetch the flake should not be presented as having completed every step required to select and obtain a specific revision.
The distinction is useful in debugging too. A surprising source can originate in a registry mapping, while an unexpected revision can arise later in source selection or locking. Showing the direct reference isolates the naming question before investigating the resulting source state.
Nix already limited local-registry influence on flake lock generation in its January release. That earlier change and today's registry command have different scopes. The new command explicitly inspects available registries, while lock generation has its own rules about which registries participate. Its result is not a substitute for examining the project's declared input and lock. A local override may explain the answer shown by this diagnostic without establishing that the same override belongs in shared dependency metadata. The operation being inspected determines which resolution rules are relevant.
Cloning now includes tarball inputs
The release notes expand nix flake clone beyond its previous input restrictions. In particular, a tarball-published flake can now become a local source tree through this command. That is useful when the published source artifact is not being addressed through a Git or Mercurial clone URL.
The released command implementation requires a destination supplied through --dest. It resolves the flake reference and delegates cloning to the input implementation. The command therefore shares reference resolution with other flake operations while leaving acquisition behavior with the selected input type.
This should not be confused with archiving every input in a flake's dependency graph. The same source file implements nix flake archive separately, traversing the locked inputs for that operation. Cloning the selected flake and archiving its dependency sources serve different purposes.
I find the distinction useful for inspecting published configurations. A reference lookup can establish which source is intended, and cloning can then obtain a local tree for examination. Neither operation needs to be described as deploying the configuration or making its entire dependency graph available offline.
Source acquisition also receives implementation improvements
Nix 2.33 changes Git revision-count calculation to use multiple threads. The release notes explain that long histories can make revCount expensive and identify shallow = true as an option when that count is not needed. This is work performed while obtaining source metadata, independently of evaluating the resulting configuration.
The release also changes HTTP binary-cache uploads to stream compressed NAR content instead of buffering the entire compressed archive. Its stated constant-memory behavior concerns the upload path. It does not claim that every operation on a large source or store object now has constant total memory use.
Download backpressure receives a related repair. Nix uses libcurl's write-pausing facility when a consumer, such as the tarball cache, cannot keep up. The notes say the default download buffer is now one MiB and that increasing it is no longer the recommended response to the earlier warning. Controlling the producer's progress addresses a different problem from allocating a larger queue.
December's naming and cloning commands make the source workflow easier to separate into concrete operations. Registry resolution shows the direct reference without fetching. Cloning obtains the selected flake through its input type and a declared destination. A configuration's locked dependency state remains a separate artifact to inspect when the question is which exact source revision a reproducible build uses.