I dunno, I don’t trust a guides still recommending flake-utils. You can make the same four loop in like 4 lines of Nix which is a smaller diff & doesn’t pollute your downstream consumers with a useless dependency. Flakes also don’t eliminate pointless builds, fileset or filtering the src can & the only tool with file tracking on by default is the Git VCS specifically (which also involves the intent to add flags which is the other side of annoying).
I sometimes write a flake with those 4 lines of Nix code, and it comes out just messy enough that tbh I’m happier adding an input to handle that. But I recently learned that the nixpkgs flake exports the lib.* helpers through nixpkgs.lib (as opposed to nixpkgs.legacyPackages.${system}.lib) so you can call helpers before specifying a system. And nixpkgs.lib.genAttrs is kinda close enough to flake-utils.lib.eachSystem that it might make a better solution.
Like where with flake-utils you would write,
flake-utils.lib.eachSystem [ "x86_64-linux""aarch64-darwin" ] (system:
let
pkgs = nixpkgs.legacyPackages.${system};
in
{
devShells.default = pkgs.mkShell {
nativeBuildInputs = with pkgs; [
hello
];
};
})
Saving the dependency is pretty big since each flake you import will bring along its jungle of dependencies now in your downstream project. I can’t think of a use case where < 10 lines is worth a dependency—especially since as you noted, lib has the glue right there for you to put it all together.
I dunno, I don’t trust a guides still recommending flake-utils. You can make the same four loop in like 4 lines of Nix which is a smaller diff & doesn’t pollute your downstream consumers with a useless dependency. Flakes also don’t eliminate pointless builds, fileset or filtering the src can & the only tool with file tracking on by default is the Git VCS specifically (which also involves the intent to add flags which is the other side of annoying).
I sometimes write a flake with those 4 lines of Nix code, and it comes out just messy enough that tbh I’m happier adding an input to handle that. But I recently learned that the nixpkgs flake exports the
lib.*helpers throughnixpkgs.lib(as opposed tonixpkgs.legacyPackages.${system}.lib) so you can call helpers before specifying a system. Andnixpkgs.lib.genAttrsis kinda close enough toflake-utils.lib.eachSystemthat it might make a better solution.Like where with flake-utils you would write,
flake-utils.lib.eachSystem [ "x86_64-linux" "aarch64-darwin" ] (system: let pkgs = nixpkgs.legacyPackages.${system}; in { devShells.default = pkgs.mkShell { nativeBuildInputs = with pkgs; [ hello ]; }; })Instead you can use
genAttrs,let forAllSystems = nixpkgs.lib.genAttrs [ "x86_64-linux" "aarch64-darwin" ]; pkgs = forAllSystems (system: nixpkgs.legacyPackages.${system} ); in { devShells = forAllSystems (system: { default = pkgs.${system}.mkShell { nativeBuildInputs = with pkgs.${system}; [ hello ]; }; }); }It’s more verbose, but it makes the structure of outputs more transparent.
Saving the dependency is pretty big since each flake you import will bring along its jungle of dependencies now in your downstream project. I can’t think of a use case where < 10 lines is worth a dependency—especially since as you noted,
libhas the glue right there for you to put it all together.