Feedback on flake-parted nix config repo structure


After having been a Nix/NixOS user for 2-3 years, I wanna make my config more modular, I want it to follow the principle of each file/derivation does one thing, and does it well.

One thing, for instance (that I’m tired of), is having an unfree.nix file. It’s just basically a huge list I have to separately maintain when I configure/install different packages in different files all over the place (read: where it feels like the package belongs).
Why should I have to edit more than 1x file to get a certain derivation/config done right?

(If it’s a package I build myself, I am perfectly happy with a separate file that permits the callPackage paradigm, while the config lives elsewhere).

Another thing, is that I would like to move away from the tree of imports = []; across files.
I am keen on implementing some sort of function myself that auto-imports all files’s configs in a folder-structure (say home-manager specific modules inside of the folder modules/home-manager), which I can then import via something like self.x10.modules.home-manager.programs.terminal.editors.helix`.
(See examples here, and here).

In general, it seems like’s goals/design principles match my wishes very well.

On recommendation from @Nobbz, I tried to spend some hours this evening and write up a “Design principles” document.

I’m hoping some will want to read through my wall of text and give me some feedback on good ideas/bad ideas/potential footguns and/or alternate (hopefully better) solutions that satisfy the design intentions I’ve described.

NB: I am confident that I’m nowhere near competent wrt. Nix/NixOS modules system, but I liked @Nobbz set-up (what I could understand of it), and I was hoping to base my 2nd gen Nix/NixOS config repo on theirs.

1 Like

Here are my notes on design principles so far: ~x10an14/nix-parts-conf - sourcehut git

1 Like