Declaring an unused variable called "extensions" leads to an assersion failure evaluating NixOS

[hacker1024]

Describe the bug

Since NixOS/nixpkgs@6980e6b, some part of NixOS seems to fail to evaluate completely if a variable called extensions has been declared.

Steps To Reproduce

Here are two similar examples that reproduce this problem. Test them with nix-instantiate path/to/file.nix. A copy of Nixpkgs with the aforementioned commit (nixos-unstable or newer at the time of writing) is assumed to be in the Nix path.

Example 1:

This demonstrates the issue simply. extensions should not have any effect on evaluation, but it does. Renaming or removing extensions prevents the issue from occurring.

{ pkgs ? import <nixpkgs> { } }:

let
  baseSystem = pkgs.nixos { };
  extensions = [ ];
in
baseSystem.config.system.build.vm

Example 2:

This is a little more nuanced. If either extensions is renamed/removed, or the use of lib.optionals is removed, the issue does not occur. Indeed, it seems like a closer-to-the-root cause of the first example is due to pkgs.nixos using similar library functions.

let
  baseSystem = (import (<nixpkgs> + /nixos/lib/eval-config.nix) {
    modules = (import <nixpkgs> { }).lib.optionals false [ ];
  });

  extensions = [ ];
in
baseSystem.config.system.build.vm

Expected behavior

Evaluation should not be affected by the presence of the extensions variable.

nix-env --version output

Tested on the following:

• nix-env (Nix) 2.15.1 (x86_64-linux)
• nix-env (Nix) 2.16.1 (aarch64-linux)

Additional context

The issue occurs both with and without GC_DONT_GC=true.

Priorities

Add 👍 to issues you find important.

[hacker1024]

I am pasting the evaluation failure log from our Hydra instance here in the hope that it shows up in search results and saves people debugging time.

in job ‘job’:
error:
       … while calling the 'getAttr' builtin

         at /builtin/derivation.nix:19:19: (source not available)

       … while calling the 'derivationStrict' builtin

         at /builtin/derivation.nix:9:12: (source not available)

       (stack trace truncated; use '--show-trace' to show the full trace)

       error: assertion '(final).hasSharedLibraries' failed

       at /nix/store/3z2ddp392iwz4dm4f040p55gylzcxyfg-source/lib/systems/default.nix:89:25:

           88|       extensions = rec {
           89|         sharedLibrary = assert final.hasSharedLibraries;
             |                         ^
           90|           /**/ if final.isDarwin  then ".dylib"

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/nix-language-evaluation-bug/30582/2

[ghost]

This is a bug (which I caused) in nixpkgs, not in Nix. The bug is:

NixOS/nixpkgs#244045

The fix is

NixOS/nixpkgs#244118

This particular bug filed against Nix should be closed.

[alois31]

I've seen my system configuration failing to evaluate non-reproducibly with this assert. Arguably, this non-determinism is a Nix bug. I think the comparison should have at least a well-defined order (eager is probably too slow).

[hacker1024]

I've seen my system configuration failing to evaluate non-reproducibly with this assert. Arguably, this non-determinism is a Nix bug. I think the comparison should have at least a well-defined order (eager is probably too slow).

I agree with this, especially as there is no reasonable expectation for the examples I gave to change this behaviour - the neighbouring extensions variable has no relation to the module evaluation at all from a language perspective. This is a confusing Nix implementation detail leaking through.

[Ma27]

This particular bug filed against Nix should be closed.

Even if people don't consider this a bug, we should somehow catch this behavior to make sure this doesn't happen in the wild (or document it somewhere prominently). Even though I consider myself pretty seasoned in terms of Nix hacking, I would've started questioning my sanity if I stumbled upon this behavior.

EDIT: AFAIU without the extensions binding defined, the extensions attribute from lib/systems.nix wouldn't have been forced (because the platform check would've failed earlier), but with another extensions being forced(?) - i.e. the one in the let-in bidning, it will be evaluated when comparing two platforms (and #8711 actually forces all attrset values to trigger this kind of error), correct? In that case the extensions evaluation would happen because of something completely unrelated which is IMHO a bug. Not entirely sure though, I'm still not sure if I fully understood what's up here.