After nine moths of using flake-parts in several projects I’ve refactored my personal infrastructure repository to adhere to a pattern; each Nix file is a flake-parts module.
I have found this pattern liberating and therefore sharing. The readme has a few words on the matter.
How is that some modules are a function that return an attribute set, others are a function that return an attribute set whose main value is also a function and others are plain attribute sets?
Modules are of the structure x or moduleArgs: x, where x is some conformant attrset.
In flake-parts there are nested module system evaluations, so you could have fpModuleArgs: { perSystem = perSystemModuleArgs: perSystemAttrs; ... }, and so on. I guess that’s why some find f-p confusing to use.
I don’t find fp confusing at all. I’m more than used to high order functions (in either direction, taking or returning functions), recursion and all the usual jazz. But after reading the flakes on that repo, and reading probably 55% of flake-parts docs I was completely oblivious at what is making possible to return one or the other, and even worse, what to expect as input or what will be produced as output.
This black magic is probably very convenient, but it is very hard to understand for a newcomer
That looks like a file that is a NixOS module, isn’t it? In the pattern I’m describing each file is a flake-parts module. All files are flake-parts modules.
I guess I can see the advantages of importing all files instead of having to follow a predefined folder structure (like rails conventions). Reading your configs I can see the advantage of defining cross-cutting concerns independent of the file location.
I’ll be exploring your pattern on my own setup, and will use flake-parts a lot more on my published nix flakes :).
Now , -at the cost of being taken as a person who would publish two-lines isEven function as an npm package- I just published a flake inspired by yours here:
But that’s quite the opposite of what’s presented in the “every file as module” idea.
I have specially written a module loader based on haumea, whether it is every file as module or importNixOS modules as a tree or other hierarchical requirements, it depends on the direct functions of the loader and transformer.