Add nix check command (#13805)

[roberth]

Motivation

I can't do it anymore.
Yesterday I've made this mistake more than once:

nix run .#checks.x86_64-linux.something

It's horrible to type, and to add insult to injury, it fails because of my own stupidity.

I need to rewire my brain to type something sensible and nice.

nix check .#something

• Quick to type
• Quick to run

I'm dogfooding this. Pretty great so far.

Context

• Closes nix check subcommand #13805
  • for now, if no fragment is provided, it tells you to use nix flake check instead
  • ... leaving room to rejiggle the impls

• Run a single flake check #8881

---

Add 👍 to pull requests you find important.

The Nix maintainer team uses a GitHub project board to schedule and track reviews.

[edolstra]

It's confusing that this doesn't check the same things as nix flake check, i.e. perform the same eval checks, only just for the specified installables. So it may be less confusing to call it nix build --check-only or something like that, to make clear that it builds and doesn't support non-buildable flake outputs.

[roberth]

@edolstra but then it would be confusing that it looks up in checks first, or at all.

I think we could unify nix flake check and nix check, because the prior wants a flake and the latter tends to want an attribute. Then the "confusing" part is that nix check flakref-no-fragment checks more than the checks, but at least checking "too much" is erring on the safe side. I think checking the whole flake is quite reasonable when the whole flake is specified.

--check-only is quite a nice addition to nix build I think; just not a replacement for a nix check flake#attr UX.
We can then say: nix check operates in --check-only mode by default.

As for moving this forward, I think this is a good incremental step. I think it'd be good to integrate this with nix flake check, and we have that possibility because nix check currently rejects whole-flake installables, and nix flake check rejects the opposite: flake attributes.

The only changes I would expect to follow from this integration is having more eval-level checks in nix check, and perhaps a better behavior for e.g. nix check .#nixosConfigurations.foo.

[roberth]

Suggested change

	"checks." + settings.thisSystem.get() + ".",
	"packages." + settings.thisSystem.get() + ".",
	"legacyPackages." + settings.thisSystem.get() + "."};
	"checks." + settings.thisSystem.get() + "."
	};

Having all the packages in the completions is counterproductive, and I haven't wanted to check buildability of a package yet.

[Eveeifyeve]

Look it's looking good so far. However it still needs to check the build ability of the package as well as potentially adding completions. Because this would help a user in this case, knowing exactly what to use, but this is not needed and be done in another pr later.

Something you want to look into is moving the nix flake check command to an alias with a warning of deprecation before deprecating.

This pr also needs a rebase to utilize new nix cpp code. EDIT: I have rebased this pr at https://github.com/DigitalBrewStudios/nix/tree/issue-13805 so all you need to do is a reset hard on the changes.

[Eveeifyeve]

Something to consider here as well, to support on a non flake system, because nix check Implies from a user perspective seems that it can run checks from a non flake system as well.

I am not too sure how it would work logically, if it's a separate file like checks.nix or something to do with default.nix.