Catching typos in attr names

Development
1

Consider this default.nix:

{
  pkgs ? import <nixpkgs> { },
}:

pkgs.mkShell {
  buildInpts = [ pkgs.bashInteractive ];  # Notice the typo in buildInputs
}

Now, “obviously”, this is just an attrset and it doesn’t care about what the keys are. Something else somewhere later may or may not. So, nix shell just starts a shell.

This is a bit of a general question, and may result in Opinions, but: Do you think it will ever be possible in the Nix ecosystem to catch mistaken or unused attributes like this? Is it even desirable? What would it take?

I think this has been, as a relatively beginning Nix user, probably my biggest grief; not typos per se, but not knowing what has an effect where. I can set values in different places, and maybe they do something, or maybe that attr is never even read by anything in this context. I feel it encourages cargo culting. I’m shocked if my config doesn’t contain a lot of values that never get touched, despite trying to be conscious about this problem.

2

There are a couple of mechanisms already in Nix/NixOS for catching this sort of thing:

  • In Nix, a function can be written to accept an attrset with a fixed set of attribute names, like so: { a, b }: a + b. Nix will error if you try to give that function an extra name.
  • The NixOS module system has (eval-time) type checking and won’t allow config values that aren’t pre-declared. The exceptions are cases where options are explicitly free-form, like systemd service definitions for example. But most of the time, if you misspell an option, NixOS will ‘did you mean…’ you instead of ignoring it.

Functions that produce derivations, like mkDerivation and mkShell, aren’t subject to either of these because historically extra attributes to these functions are interpreted as build-time environment variables. There’s a general trend toward moving those to env, but because of backward compatibility, the option to leave them at the top level of the attrset will probably never go away, and for that same reason it’s probably hard to implement a linter that can reliably catch them too.

3 Likes
3

Interesting, thanks for the history!

This also sounds like nixpkgs could be somewhat automatically converted to put them explicitly in the environment, and then to preserve functionality of legacy code outside nixpkgs, the derivation making functions changed to issue a warning when an unknown attr is defined (but keep putting it in the build time environment for perfect backwards compatibility).

Obviously this would be massive churn. Would it be welcome work?

1 Like
4

I don’t know if it’d be anywhere near easy enough to do given the benefit, but ignoring implementation difficulty it sounds good in principle! I don’t know if there’d be community consensus behind a big migration PR, but something like the ratcheting policy used for pkgs/by-name would be less disruptive and would get us there asymptotically.

The other nit I can think of is that warnings tend to be fairly invisible in Nix — they’re easy to miss among the rest of the output that builds produce. The ideal thing here might be to have a Nixpkgs config flag, off by default, that makes extra attributes throw.

1 Like