Nix / NixOS @programming.dev bijectivehomomorphism @programming.dev 3d ago

Thoughts on flake-parts?

I've been working on my configuration for a while now using flakes. I can already understand the appeal of flake-parts, and my configuration has always been spread out across multiple files according to specific features. ATM I don't really have any good modules to share, but what's your opinion?

7 comments

I don't really like flake-parts or flakelight. I think that part of this is sheer brutalism (I don't mind writing bare Nix) but part of it is a desire to not rely on flakes which don't carry their own weight, following Wirth's principle for compilers.

That said, github:numtide/flake-utils does carry its own weight by managing multiple system values, especially in flakes that support more systems than upstream nixpkgs, and I've found myself using it in nearly everything; flake-utils makes it fairly easy to have leaf packages that are e.g. supported on both amd64 and aarch64. I know flake-parts does this too, but not in a way I enjoyed.

I just noticed that you said "my configuration." A machine, perhaps? My NixOS configuration is split into over a dozen NixOS modules and each machine has a list of included module files. I'm not using any flake-management tools for that flake; each machine has a hardcoded system and (like sibling comment from @[email protected]) they're all crammed into one big flake.nix so that the machine hostnames line up correctly when using the flake in argv:

$ sudo nixos-rebuild switch --flake git://git.example.local/one.big.flake.git

Seems facetious at first, but it facilitates automatic updates via flakes, just like with classic channels.
- I don't really like flake-parts or flakelight. I think that part of this is sheer brutalism (I don't mind writing bare Nix) but part of it is a desire to not rely on flakes which don't carry their own weight, following Wirth's principle for compilers.
  
  How can you say this and still use flake-utils? All it does is manage your systems. You can write your own one-liner for that
  
  eachSystem = f: lib.genAttrs systems (system: f nixpkgs.legacyPackages.${system});
  
  Where systems is automatically supplied as a flake input (I think), or you can supply your own list of systems to support. You can then use it like this:
  
  devShells = eachSystem (pkgs: { default = # your devshell }
  
  You can of course modify eachSystem to have more function parameters other than pkgs.
  
  See this blog which initially inspired me not to use flake-utils
- Hey thanks, this is the sort of perspective I was looking for. As far as you've revealed, I'm pretty sure we have nearly the same setup.
  
  I wanted to see if flake-parts would be any enhancement, but it seems not since I'm also managing servers with along with my personal huge flake. I'm working on moving git-crypt out of my config so I can rebuild it straight from git, but I can't find a way to declare my email in secrets (sops-nix you're good at everything but...not trivial secrets)
I used to use flake-parts, but I organize my flakes in a very different way (I generate a single, bigass flake.nix out of tiny org files), and found that frameworks like flake-parts and flakelight just get in the way. I suspect they're useful if you're working with Nix directly, but... I don't like Nix (the language), so I do my organization outside of it.
I use https://github.com/nix-community/flakelight, since it requires even less boilerplate
@bijectivehomomorphism
IMO, the best flake framework.
I really like it for devshells which is really all I use Nix for. Flake-parts automates so much boilerplate and improves the error messages so much compared to standard flakes. Definitely worth the time investment imo

7 comments