Implement check to disallow pkgs/by-name package definitions in all-packages.nix with an empty argument

[infinisil]

Description of changes

This PR extends the nixpkgs-check-by-name tool to allow checking that packages in pkgs/by-name cannot also have a definition in all-package.nix with an empty attribute set.

In order to allow a smooth CI change, the check is not enabled by default for now. It has to be enabled with --version v1. I will update CI to use this in a future PR. This PR here only updates the tool to support this new check. This way we sidestep the problem of #256788 for now.

Example

If pkgs/by-name/fo/foo exists, this would be disallowed in all-packages.nix:

  foo = callPackage ../by-name/fo/foo/package.nix { };

because the second callPackage argument is an empty attribute set.

RFC relation

This notably is a minor violation of what RFC 140 specifies:

Optionally there may also be an overriding definition of pkgs.${name} in pkgs/top-level/all-packages.nix equivalent to

pkgs.callPackage pkgs/by-name/${shard}/${name}/package.nix args

with an arbitrary args.

However I don't think there's a good reason this shouldn't be done.

By disallowing empty arguments, we can be sure that new packages that don't need any arguments aren't unnecessarily added to all-packages.nix.

Furthermore, we can ensure that if packages are refactored to not need custom arguments anymore, they get removed from all-packages.nix, and don't linger around unnecessarily.

I asked whether anybody had any problems with this on Matrix and in the last NAT meeting, but there were none.

Things done

• Wrote a test
• Ensure that CI can handle old and new Nixpkgs regarding the new _internalCallByNamePackageFile that is necessary to perform this check
  • This turns out to not be a problem, because we'll always run older versions of the tool on potentially newer versions of Nixpkgs

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2023-10-03-nixpkgs-architecture-team-meeting-44/33798/1

[infinisil]

While there's no current violations of this (I thought there was one, but turns out it was a fake), this is a good exercise for future increases in CI strictness.

[tomberek]

I would have said this is premature and not needed yet, but that should not block this if we already can use it.