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 @algernon@lemmy.ml) 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 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