Nix 2.15 makes derivation output selection explicit
Nix 2.15 stops treating a bare derivation path as shorthand for its outputs. Explicit selectors distinguish a build description from the artifacts it describes.
A derivation is a build description, and its outputs are the artifacts produced from that description. Treating a path ending in .drv as shorthand for those outputs makes a command's target depend on an implicit suffix rule. That can obscure whether a script is inspecting the description or the resulting packages.
Nix 2.15 removes that special handling. The release notes, dated April 11, say a bare derivation installable now means the literal store path it names. Their release-tag version identifies the explicit ^ output-selection syntax as the replacement for implicit output selection.
I value Nix's ability to make build inputs and system state explicit. This change applies the same preference to the command interface. A script should be able to name a derivation itself without the parser silently replacing that target with a set of outputs.
A store path and its outputs are different targets
The release demonstrates the distinction with nix path-info. Supplying a bare .drv path now requests information about that derivation. Appending ^* requests information about all its outputs. The output selector makes the requested relationship visible in the argument.
The following example uses the release note's illustrative store path. It requires that path to exist in the store being queried.
nix path-info /nix/store/gzaflydcr6sb3567hap9q6srzx8ggdgg-glibc-2.33-78.drv
nix path-info '/nix/store/gzaflydcr6sb3567hap9q6srzx8ggdgg-glibc-2.33-78.drv^*'
Quoting the second argument keeps the asterisk from becoming a shell filename pattern. Nix needs to receive the selector itself. The two commands then ask the same tool about different store objects through explicit syntax.
This is a compatibility change for scripts that relied on the previous suffix interpretation. A script can remain syntactically valid while receiving information about the derivation instead of its outputs. The migration therefore concerns the intended target, not merely whether the command parses.
The release notes say the explicit syntax arrived in Nix 2.13. Its availability before removal gives callers an expression for the old intended operation. A script that really wants outputs can state that requirement instead of relying on the derivation filename to imply it.
Outputs already have independent identities
The build command documentation at this version describes installables that resolve to derivations and installables that name store paths. Derivations can be built or substituted, while store-path installables can be substituted. The interface therefore already distinguishes descriptions requiring realization from existing artifact identities.
Multiple outputs also affect result links. The command documents link suffixes based on the installable's position and output name, with special omissions for the first installable and the default out output. That behavior shows why an output selection can affect more than the information printed on the terminal.
An explicit selector helps preserve the intended set of artifacts. Selecting all outputs is a different request from selecting one named output. The derivation path alone cannot communicate which of those operations a caller means without an additional convention.
This matters for automation that handles development files separately from runtime packages. The output name identifies the intended artifact class, while the derivation identifies the build description behind those artifacts. Keeping both visible helps a reviewer determine what a command is actually about to inspect or realize.
Standard input removes an argument-size constraint
Nix 2.15 also lets commands that take installables read them from standard input with --stdin. The notes identify a concrete motivation, namely lists of paths large enough to exceed the operating system's command-line argument limit.
This changes how a collection reaches Nix without changing what each installable denotes. A producer can supply the list through a stream instead of placing the entire collection in a process invocation's argument vector. Explicit target syntax remains relevant inside that collection.
The distinction is useful when reviewing a pipeline. Moving arguments to standard input solves transport of the list. It does not decide whether an entry means a derivation or its outputs. Combining the new transport with explicit selectors lets a script address both questions independently.
The release does not present --stdin as a new way to infer missing targets or bypass store permissions. It is an input mechanism for commands that already accept installables. Its practical value comes from removing the size limit of the old argument-passing arrangement.
Hash representation becomes another explicit choice
The nix-hash reference documents Base64 and SRI output alongside the older encodings. Nix 2.15 adds --base64 and --sri, plus conversion options for those representations. It also adds an explicit --base16 option while retaining hexadecimal output as the default.
Choosing an encoding does not choose what bytes get hashed. By default, nix-hash hashes a NAR serialization of the path, which can represent a directory tree or symbolic link. The --flat option instead hashes a regular file's contents. The selected hash algorithm is yet another independent parameter.
For example, a SHA-256 SRI hash of a regular file's bytes uses these options together. The file must be present at the named path.
nix-hash --type sha256 --flat --sri archive.tar.gz
SRI output prefixes the Base64 body with the algorithm name. That makes the textual representation more self-describing, but it does not turn a recursive tree hash into a flat file hash. A caller comparing hashes still needs the hashing mode and algorithm to agree.
Another change gives derivation descriptions an explicit round trip. The new nix derivation add command consumes the JSON layout emitted by nix derivation show. Both now include the derivation name as a top-level field. The release notes describe this as plumbing for alternative frontends, allowing a producer to submit a build description without involving the Nix language.
I find the relationship between these changes useful for command design. Nix 2.15 gives callers explicit ways to name outputs and hash representations, while retaining separate controls for the underlying operation. A derivation selector chooses an artifact relationship, and a hash flag chooses an encoding. Neither should require a script's reader to guess from a filename suffix or an unstated convention.