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

Created on 11 Sep 2019  路  9Comments  路  Source: NixOS/nix

To reproduce:

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

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

$

Most helpful comment

@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.

All 9 comments

~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

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 = { ... }; }

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.

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

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

This behaviour is intended: b0cb11722626e906a73f10dd9a0c9eea29faf43a

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

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

@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?

@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.

Was this page helpful?
0 / 5 - 0 ratings