nix-build ignores attributes with a period {"a.b" = drv}

[roberth]

To reproduce:

$ nix-build --expr '{ hi = (import <nixpkgs> {}).hello; }'
/nix/store/...-hello-2.10

$ nix-build --expr '{ "hi.there" = (import <nixpkgs> {}).hello; }'

$

[matthewbauer]

I think this just gets rewritten as:

$ nix-build --expr '{ hi = { there = (import <nixpkgs> {}).hello; }; }'

And Nix only builds the top level derivations. This behavior can be changed with recurseForDerivations:

$ nix-build --expr '{ hi = { recurseForDerivations = true; there = (import <nixpkgs> {}).hello; }; }'

Actually this does look like a bug! hi.there is treated as top-level, but ignored later on

[zimbatm]

When the key is quoted, it should be the name of the key.

nix-repl> { "hi.there" = 4; }
{ "hi.there" = 4; }

nix-repl> { hi.there = 4; }   
{ hi = { ... }; }

[roberth]

If that were the case, I'd expect this to work, but it doesn't:

$ nix-build --expr '{ "hi.there" = (import <nixpkgs> {}).hello; hi.recurseForDerivations = true; }'

$

To be clear, I don't want this example to work. It would mess up the meaning of attribute sets.

[zimbatm]

Here is another example that doesn't work as expected:

$ nix-build --expr '{ "3des" = (import <nixpkgs> {}).hello; }'

[edolstra]

This behaviour is intended: b0cb117

[zimbatm]

@edolstra is the goal to make those disallowed on the language level as well on the longer term?

[edolstra]

@zimbatm No. But generally it's a good idea to avoid them.

[roberth]

@edolstra This is applying Postel's law (be conservative in what you do, be liberal in what you accept from others) to the Nixpkgs+nix-build combination. Works well for Nixpkgs.

I would like nix-build by itself to be a simple, predictable tool, by being liberal in what it accepts.

As an alternative to the filtering in nix-build, Nixpkgs may enforce its constraints by filtering out the bad attribute names as the last step in pkgs/top-level/default.nix. Is that a acceptable solution?

[zimbatm]

@edolstra if I understand it correctly, your goal was to avoid contributors from adding those attributes to nixpkgs?

I find it surprising that those attributes get filtered out on the nix level. It adds another hidden behaviour that is only discovered after looking into the nix source code, or after finding this issue.

[stale]

I marked this as stale due to inactivity. → More info

[roberth]

I still believe Nix can do better than this. We ought to fix root causes, not introduce more problems by adding unnecessary restrictions.

[zimbatm]

I completely forgot about this issue and got bitten by it again last week

[stale]

I marked this as stale due to inactivity. → More info

[rimmington]

Ran into this today when an attribute path containing a : mysteriously didn't build with nix-build.

If the Nix language permits attributes to be named with these characters, the tooling should work with those attributes.