Nix-grove: Configuration framework for flake-parts

Announcements
1

AI USAGE: I used ChatGPT (GPT-5.6-Sol) to assist with design and planning, and Pi with GPT-5.6-Luna via openai-codex to help with implementation

Sort of an “alternative” to the Dendritic pattern. Still is about importing a bunch of flake-parts modules, but uses the module system for more, instead of import=enable.

2 Likes
2

Hello,

Thanks for sharing, I will definitely have a look.

I am a user of the Den framework (framework is not the most appropriate name, but let’s forget that discrepancy for the time being). What are the differences, pros and cons of your project compared to it ?

Thank you again !

1 Like
3

I have not used Den, but I have used (and am currently using, since I have just pushed this to GH and have not rewritten my config yet) flake-aspects, and the reason I made my framework/library/thing is to use the module system with mkIf and mkEnableOption, instead of the import=enable pattern. It seems like Den has maybe some nicer ways to compose than raw flake-aspects, but I never was able to wrap my head around it.

One of the things that (theoretically, I have no use-case for it right now) bugs me about flake-aspects and similar import=enable-based frameworks is that if I have, say, a GUI aspect that included many sub-aspects that install GUI programs, there’s no simple way to run 1 off for a specific host, as far as I can see. Very contrived example of what you might want:

  • host1
    • gui aspect
      • Firefox
      • mpv
      • Spotify
  • host2
    • gui aspect
      • Firefox
      • mpv
      • NO Spotify

With flake-aspects, as far as I can tell, there is no way to disable aspects included by other aspects, so, say, if you want to import gui aspect without gui._.spotify. You could do this by just not importing gui._.spotify in gui, among other workarounds or refactors, but it still bugs me.

The other, less theoretical contrived issue I have with flake-aspects (which Den might help with!) is that to enable wayland compositor configuration for some software (desktop shells, etc) is that I have to use (lib.mkIf (lib.attrByPath [ "programs" "niri" "enable" ] false config) { programs.niri.settings.binds = { }; }) on the home-manager side to check whether Niri is enabled, and it seems like there should be a cleaner way to do this! (again, I don’t have any hosts with Niri disabled, or some other Wayland compositor replacing Niri, but this bugs me!)

And I just would like to try using the module system more again instead of import=enable. Used to do this with flake.modules.generic.default but I did not have a good distinction between host/user, which is why I switched to flake-aspects.

1 Like
4

Started migrating my personal config (starting with migrating Firefox) so you can see some real use of this:

1 Like
5

Not to mention that this is really minimal compared to den. I know den does a lot but it’s 169 LoC for grove and a whopping 1585 for den’s modules folder, which seems to be the non-glue parts. Even if you exclude the “batteries” you’re left with 617 LoC. flake-aspects gets a little closer, with just 229 LoC when you only count the “important parts” (i.e. the files that get imported when you use the flakemodule)

1 Like
6

Den is probably even more if you include its dependencies, gen-schema and nix-effects, and its nix/lib folder.

1 Like