Nix 2.20 separates evaluation settings from build execution
Eval-system avoids changing local scheduling when selecting an evaluation platform. Build statistics also reach clients across daemon and ssh-ng connections.
Choosing which system an expression describes should not accidentally tell the scheduler that the local machine can build for it. Nix 2.20 introduces eval-system to separate those choices. It overrides builtins.currentSystem without taking on the scheduling effect of the existing system option. That is a useful distinction when evaluation and building happen on different machines.
The 2.20 release notes date the release to 29 January. They also describe cgroup statistics reaching clients through daemon and remote ssh-ng connections. Taken together, these changes improve the boundary between describing a build and observing where its execution takes place.
I am interested in Nix because a declarative machine configuration can state the result being requested in a form that can be rebuilt. The awkward part is often knowing which part of the tool is interpreting a setting. A setting that affects evaluation and scheduling at once can make a configuration mean more than its author intended.
Eval-system changes the value seen by evaluation
The proposal for eval-system explains the motivation directly. Overriding system changes builtins.currentSystem, but it also changes scheduling. Nix can then attempt to build locally for the selected system even when that is inappropriate for the machine running the command.
The new setting changes only the value exposed through builtins.currentSystem. A derivation produced by that evaluation can still go to a remote builder capable of handling its system. The evaluation choice no longer has to imply the same change in the local scheduler's view.
eval-system = aarch64-linux
This setting illustrates the separation. It supplies a system value to evaluation. It does not provision a builder or establish that the local machine supports that platform. The remote-builder arrangement remains a separate part of the configuration, which is precisely why separating the settings is useful.
The default is an empty value. In that case, evaluation continues to use system as before. Existing configurations do not need to add the new setting merely to retain their current behaviour. The release introduces a more selective override for callers who need one.
This is also narrower than promising cross-compilation. The documented change concerns the value of a builtin and its relationship to scheduling. A package expression and its build dependencies still determine what must run where. Keeping that scope explicit avoids attributing a complete platform strategy to one setting.
Statistics cross the daemon connection
Build resource reporting has its own boundary. A client asking a daemon to build does not execute the build itself, so the client needs the daemon to return the measurements. Nix 2.20 now reports cgroup statistics through that connection and through remote builds using ssh-ng, provided both sides use 2.20 or newer.
The reporting change identifies the daemon connection forms as unix:// and ssh-ng://. That makes the addition relevant to a local daemon as well as a remote one. The important distinction is whether build information can travel through the connection used for the request.
A missing value before this change need not mean the build used no resources. It can mean the client did not receive the measurement through its execution path. That is why reporting support is a distinct concern from collecting a statistic at the builder. A measurement that stays on the far side of a protocol is unavailable to the client making the request.
The two-sided version condition matters for mixed installations. Upgrading only the command-line client does not establish that a remote daemon can supply the new information. Conversely, a newer builder does not make every older client understand it. The release notes describe a connection capability, so both ends belong in the explanation.
No performance improvement follows automatically from reporting the statistics. The build can do the same work while making that work easier to observe. The benefit is a clearer account of execution, which helps distinguish a change in the build from a change in the path through which its results are reported.
Evaluation stores and build stores also differ
Another 2.20 change applies the same separation to import-from-derivation. When --eval-store is in use, importing a derivation now builds it in the build store selected by the store option. The resulting Nix expression must then return to the evaluation store for import.
The release-tagged notes spell out the consequence. The evaluation store must trust the build store's signatures so it can accept the resulting expression. Executing a build elsewhere therefore has a trust requirement as well as a location requirement.
This is a useful concrete example of evaluation requiring a build result. Describing evaluation and building as separate activities does not mean they never interact. Import-from-derivation makes that interaction explicit, and the store selection determines where the required execution occurs.
I find this distinction more useful than treating every remote operation as the same kind of indirection. Evaluation can request a result, another store can build it, and the result must be accepted back under a trust policy. Each step answers a different operational question.
Command changes expose other assumptions
The release also requires a search regular expression for nix search. To request every package, the notes specify ^. That makes the broad search an explicit request instead of a consequence of omitting the search term. The change concerns command input, without changing the evaluator-versus-builder distinction above.
Profile operations gain human-readable element names in place of indices. The notes warn that modifying a profile upgrades its manifest and makes it unusable by older Nix versions. A package-manager rollback and a profile-format rollback are therefore different concerns. The manifest compatibility rule remains relevant even when a particular installed package has not changed.
For a distributed build setup, the selective evaluation override and the expanded reporting are the more direct changes. One prevents the expression's chosen system from unnecessarily altering local scheduling. The other lets a client receive resource information from the daemon carrying out the request. They make two existing boundaries more accurately reflect the work on each side.