flake: drop flake-utils

[MattSturgeon]

I noticed we were using flake-utils, which is a bit of an overkill dependency for our minimal flake setup.

• Drop flake-utils
• Depend on nix-systems directly (instead of transitively).
• Implement a minimal mapAttrs-based "for each system"
• Re-implement genAttrs, instead of instantiating an extra nixpkgs/lib instance

[github-actions]

Nixpkgs diff

[jfly]

LGTM. We could use the pinned nixpkgs's lib if you want some quality of life helper functions, though.

Reading this code made me realize 2 surprising things:

• I hadn't realized our default.nix returns a derivation. Kind of odd. I guess the intent is to abstract all the other details away from folks who just want our main package.
• I don't think we need to provide the apps.default. nix run will use packages.${system}.default if it doesn't find an apps.${system}.default.

[MattSturgeon]

• I hadn't realized our default.nix returns a derivation. Kind of odd. I guess the intent is to abstract all the other details away from folks who just want our main package.

It's also a bit inconvinent, as the derivation uses IFD and in order to evaluate other unrelated attrs, we need to evaluate the IFD. This means nix flake show also needs --option allow-import-from-derivation true if you have it disabled elsewhere like I seem to.

• Kind of odd. I guess the intent is to abstract all the other details away from folks who just want our main package.

Yeah, I guess the intent is to support nix-build without arguments building the default package.

Out of scope for this PR, but worth considering a refactor where we move most of default.nix's impl details to another file so that we can evaluate them more lazily.

• I don't think we need to provide the apps.default. nix run will use packages.${system}.default

IIUC it's still a best practice to define apps.default. Mostly so that you can give it a description, which we aren't doing, though.

Happy to add a description or drop the app, but again probably worth a separate PR.

We could use the pinned nixpkgs's lib if you want some quality of life helper functions, though.

There are a few ways I could've got a nixpkgs lib instance, from our npins. The reason I avoided it is that it's quite wasteful to evaluate an instance of nixpkgs/lib if we're only going to use that instance for a trivial function like genAttrs. If we had a nixpkgs flake input that comes with a lib flake output, I'd use that. If we had a way to reuse a lib instance in the default.nix eval, I'd do that. But currently we'd be instantiating lib once in the flake and again in default.nix (plus any third-party inputs that also instantiate their own libs, like treefmt-nix).