[Nix#8837] Schrödinger's Attribute #124

New issue

Closed

opened 2024-03-16 06:45:02 +00:00 by lix-bot · 1 comment

lix-bot commented

2024-03-16 06:45:02 +00:00

Member

Upstream-Issue: NixOS/nix#8837

Describe the bug

Attributes can apparently be both defined and missing at the same time (spukhafte fernwirkung).

Steps To Reproduce

Defined

$ nix eval --show-trace --impure --expr '
let
   foo=((import <nixpkgs> { inherit (builtins) currentSystem;}).lib.attrsets.genAttrs ["a"] (_: {b="c";})); 
in
foo.z
'
error: attribute 'z' missing

       at «string»:5:1:

            4| in
            5| foo.z
             | ^
            6|
       Did you mean a?

vs.

$ nix eval --show-trace --impure --expr '
let
  foo=((import <nixpkgs> { inherit (builtins) currentSystem;}).lib.attrsets.genAttrs ["a"] (_: {b="c";}));
  foo.z="d";
in
foo
'
error: attribute 'foo.z' already defined at «string»:3:4

      at «string»:4:4:

           3|    foo=((import <nixpkgs> { inherit (builtins) currentSystem;}).lib.attrsets.genAttrs ["a"] (_: {b="c";}));
           4|    foo.z="d";
            |    ^

So, somehow foo.z is both defined by the first assignment and missing after the first assignment.

You can reproduce this in a simpler way with

$ nix eval --expr '{a=1; a.d="e";}' 
error: attribute 'a.d' already defined at «string»:1:2

       at «string»:1:7:

            1| {a=1; a.d="e";
             |       ^

Expected behavior

Hopefully we could find a way to make this succeed (since there's no conflict).

However, if it must fail then I think that saying that foo.z is defined when it's not is confusing. I could understand something like "foo is already defined" (and immutability prevents any changes). But, I think that even this change is a little confusing considering allowed operations like

$ nix eval --expr 'let a={}; a.b="c"; a.c="d"; in a'
{ b = "c"; c = "d"; }

Note: This may be related to https://github.com/NixOS/nix/issues/7111 .

Upstream-Issue: https://git.lix.systems/NixOS/nix/issues/8837 **Describe the bug** Attributes can apparently be both defined and missing at the same time (spukhafte fernwirkung). **Steps To Reproduce** ## Defined ```bash $ nix eval --show-trace --impure --expr ' let foo=((import <nixpkgs> { inherit (builtins) currentSystem;}).lib.attrsets.genAttrs ["a"] (_: {b="c";})); in foo.z ' error: attribute 'z' missing at «string»:5:1: 4| in 5| foo.z | ^ 6| Did you mean a? ``` vs. ```bash $ nix eval --show-trace --impure --expr ' let foo=((import <nixpkgs> { inherit (builtins) currentSystem;}).lib.attrsets.genAttrs ["a"] (_: {b="c";})); foo.z="d"; in foo ' error: attribute 'foo.z' already defined at «string»:3:4 at «string»:4:4: 3| foo=((import <nixpkgs> { inherit (builtins) currentSystem;}).lib.attrsets.genAttrs ["a"] (_: {b="c";})); 4| foo.z="d"; | ^ ``` So, somehow `foo.z` is both defined by the first assignment _and_ missing after the first assignment. You can reproduce this in a simpler way with ```bash $ nix eval --expr '{a=1; a.d="e";}' error: attribute 'a.d' already defined at «string»:1:2 at «string»:1:7: 1| {a=1; a.d="e"; | ^ ``` **Expected behavior** Hopefully we could find a way to make this succeed (since there's no conflict). However, if it must fail then I think that saying that `foo.z` is defined when it's not is confusing. I could understand something like "`foo` is already defined" (and immutability prevents any changes). But, I think that even this change is a little confusing considering allowed operations like ```bash $ nix eval --expr 'let a={}; a.b="c"; a.c="d"; in a' { b = "c"; c = "d"; } ``` Note: This may be related to https://github.com/NixOS/nix/issues/7111 .

lix-bot added the

bug

imported

labels 2024-03-16 06:45:02 +00:00

puck commented

2024-03-16 19:45:55 +00:00

Owner

I'm unsure this is actually a bug/feature we can easily resolve. At best we should improve the error message provided by this edge case; namely "cannot redefine foo" rather than "cannot redefine foo.z"?