Vertical NixOS module organisation and module dependency

[FrdrCkII]

Maybe you want to try the dendritic pattern.

It might be able to solve your first problem:

@leana8959

I find it more ergonomic to use vertically organized NixOS modules because the changes are easily grouped.

However, I do not recommend using any existing dendritic frameworks, such as den. Because I believe these ‘early practices’ did not address your second question:

@leana8959

However this module depends on agenix is not fully self-contained. Not importing agenix in this module is a conscious choice, because once it’s imported we can’t remove an import. If there are a lot of self-contained modules like this, agenix will also be imported multiple times. Is there a way to define the dependency of a module for it to work as intended? This way, the module can fail with better error message too. Instead of saying “options.age.secrets” is not defined, it would say "fileSystems.nix" module requires agenix module but this constraint is not satisfied.

So far, these frameworks use functions to deduplicate module dependencies, which is not transparent and makes error reporting harder to understand.

However, according to the design concept of the dendritic pattern, it is feasible to use module options in the top-level module to conditionally import modules, thereby controlling module dependencies. I use a similar method in my configuration (pardon the mess).

btw, I don’t want to belittle the efforts of the dendritic pattern developers. They are very friendly and have helped me in many ways. But I feel that these frameworks are a bit too complicated, and I find it hard to understand. ‘early practices’ is my honest opinion about these libraries, with no intent to offend, but I feel that they are not yet ready for use in a production environment.

EDIT: To add, I think the solution proposed in this RFC addresses the issues of module dependencies and interactions. Although this is aimed at NixOS modules, this idea has inspired me, and I believe this approach can be used in more places.

Pre-RFC: Decouple services using structured typing

Hi everyone! EDIT 2026-05-18: The RFC exists now. An matrix channel is created to provide a less formal way to talk about contracts. Summary Currently in nixpkgs, every module accessing a shared resource must implement the logic needed to setup that resource themselves. This leads to a few issues and subpar end user experience, the first one springing to mind is tight coupling between modules. I propose a solution to this issue that is fully backwards compatible and can be incrementally intro…