I cannot pinpoint any inspirations I had that is rooted in something else, except for the naming of "declaration" and "definition", inherited from C++, that is used to describe the option attribute set, and the config attribute set.

This mostly came up as a way to keep the existing configuration.nix file as-is, and extend it in a way which felt natural. At the time we had only /etc/nixos/configuration.nix and one file containing all the options declarations as part of NixOS.

The few NixOS users of the time, had all made some custom extensions of NixOS, dividing their configuration.nix file in multiple expressions by topic, but none really felt as belonging to what the configuration.nix was providing in terms of "clean" approach.

My initial goal was to extend NixOS while feeling as easy and without having to push the changes into the NixOS repository, as I had weird a PCMCIA card which had some specific kernel configuration requirements. The problem was that to make it work, I had to keep changes which modified the internals of NixOS.

Thus the only inspirations are mostly coming from the need of solving one problem after the other.

I recall having tried multiple small Nix files, trying the config argument, trying to make the "merging" function be defined outside the extending part, and outside the configuration.nix file. Having to fight infinite loop when making conditionals, having the wish to only define an option in a few cases, introducing delayIf (mkIf), Adding types as a way to refine the default merging function.

delayIf came from wanting to avoid to repeat my-self for each option that I wanted to set conditionally.

{
  a = if cond then ... else ???;
  b = if cond then ... else ???;
  c = if cond then ... else ???;
}

While also providing an answer for what was supposed to be present for the "else" part of the condition.

In reply to @infinidoge:matrix.org
I need to figure out a better way to test module stuff than shoving it in my NixOS configuration and opening the flake repl

In reply to @lorenzleutgeb:matrix.org

Hey! I have a question regarding the module system and/or generation of docs: How do I generate docs for a particular set of modules, i.e. all options defined in the modules from myservice.nix and myprogram.nix, only? Using baseModules = [] won't work, because my modules use options from NixOS. If that's not possible I run pkgs.nixosOptionsDoc for all modules and filter afterwards. Then the question arises how do I get a list of option names defined in a given module? Is that possible? As a last resort I would have to manually couple each module with some filtering expression.

infinisil pointed me at this comment, which helps, but still requires some external source of option names, e.g. I would have to know "services.maubot", and cannot start from maubot.nix, for which I don't care which option names it defines.

In reply to @roberthensing:matrix.org
Sounds like what the flake.parts site is doing. It's currently a single evaluation with everything loaded at once, and then split out with this logic: https://github.com/hercules-ci/flake.parts-website/blob/af75b73a9cb306da0789bfd326e214c6103fd646/render/render-module.nix#L81

In reply to @infinidoge:matrix.org
I need to figure out a better way to test module stuff than shoving it in my NixOS configuration and opening the flake repl

In reply to @nbp:mozilla.org
https://www.youtube.com/watch?v=lw7PgphB9qM ibizaman
https://www.youtube.com/watch?v=-Bfo3Byjwyg djacu

In reply to @ibizaman:matrix.org
In my repo I’m having module tests (example) with evalModule and integration tests (example) with nixosTests and it’s all run together with flake checks.

In reply to @infinidoge:matrix.org
I more so mean ad-hoc testing of random module things, as opposed to proper module tests, however that is something I should also do