NixCon 2018 opens discussion around a changing toolset

Nix has a new command interface whose authors explicitly say it is still changing. That makes discussion among users and contributors particularly useful, because the problems people encounter can inform an interface before it settles. The May 21 NixCon announcement announces the third Nix conference for October 25 through 27 in London and invites talk submissions. It offers a place to discuss work already changing the project, without establishing what the eventual programme will contain.

The Nix 2.0 release notes provide concrete subjects for that discussion. The release introduces a unified nix command, expands the store interface, and adds pure evaluation mode. Each change affects how a user explains a system and how a contributor implements the corresponding operation. Their practical boundaries are suitable material for technical talks, rather than assuming the conference must revolve around another release announcement.

I am interested in Nix because declarative infrastructure makes desired state inspectable. A community discussion is valuable when it clarifies the limits of that claim. The distinction between reproducible evaluation and identical build output, for example, affects how accurately a configuration can describe a machine.

An interface that still needs experience

Nix 2.0 intends its new command eventually to replace the separate nix-* programs. The release notes also say the replacement is incomplete and the interface remains subject to change. That creates a specific opportunity for user reports. A description of a task that still needs an older command is evidence about the remaining transition, without requiring a prediction about the final interface.

The new package argument handling is one example. nix copy can accept an attribute from Nixpkgs, a store path, or an expression. Older nix-copy-closure accepts only store paths. Users and tool authors therefore have more ways to identify the object they want to transfer. A useful account of that change can explain which representation a workflow already has and which preliminary work the common interface removes.

The store abstraction supplies another subject. Binary-cache substituters become implementations of the same general store interface used for other operations. Inspection and transfer can target different store types through common commands. This is an architectural change with observable consequences, such as obtaining path information from an HTTP cache instead of only from the local store.

A technical talk about that design need not claim it has solved every transfer problem. HTTP uploading still requires server support for PUT. S3 support depends on the build configuration. The notes distinguish legacy SSH access from the newer daemon-protocol store. Those differences make implementation experience informative, because the common command still operates over stores with distinct capabilities.

Reproducibility has more than one question

Pure evaluation mode addresses external influences on evaluating an expression. The release notes describe restrictions on environment access and on filesystem or network access without a content or commit hash. A Git fetch requires a revision. The intended result is that evaluating the same description does not silently select different inputs because an external source changed.

Binary reproducibility asks whether repeated builds of a derivation produce identical outputs. Nix 2.0 provides separate support for comparing build rounds, including a diff hook and an option controlling whether differing results immediately cause a fatal error. That is a different mechanism from restricting evaluation inputs.

Keeping those questions separate gives contributors a more precise vocabulary. A configuration can identify an input revision while a build process still produces differing bytes. Conversely, discussing one repeatable build result does not establish that evaluation never reads an undeclared environmental value. A talk grounded in either mechanism can describe what it establishes and what remains outside its scope.

The same precision applies to binary caches. Signatures can follow store paths between stores, but the local ultimately trusted marker does not. Transfer and acceptance are therefore separate operations. A cache demonstration can show successful publication while still needing to explain which keys a receiving machine trusts.

The announcement leaves the programme open

The May announcement invites contributions rather than naming an agreed technical agenda. It would be premature to describe a future talk, claim a design consensus, or report what participants decided. The useful observation today is that the invitation follows substantial changes whose behaviour is already documented and available to examine.

I favour contributions that explain those mechanisms through concrete operations. A store transfer, an evaluation that requires a pinned revision, or a diagnostic showing an unexpected closure dependency gives another user something specific to understand. NixCon can accommodate that kind of shared technical work without every contribution needing to propose another language feature.

The current toolset already supplies means to investigate those subjects. nix why-depends explains why a path enters another closure, while nix path-info can report closure sizes. These commands let an account of a packaging problem identify the dependency relationship responsible for it. They provide concrete material for the talk submissions the announcement now invites.