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

In reply to @nbp:mozilla.org
djacu: That might be one of the most in-depth module presentation I've seen which does not present mkIf.

In reply to @nbp:mozilla.org
I guess, I might be completely biais into introducing mkIf early, as it feels like a must have for implementing modules in NixOS. On the other hand I think your plan might actually make more sense from a user point of view and might be better to target non-developer, who might appreciate the lack of conditional.

I'd say everything I have in the "Getting Started" section must come first as it lays the foundation for how a module can be created. Anything after that is fair game.

Does documentation need to come so early? Nah but it's a quick one and a good thing to reinforce that people should document their modules well.

I had the types section in there because I wanted to get to submodules as it is the most ubiquitous and a very powerful type.

mkIf could probably go next; it was in the Future section. I was putting lessons there that I wanted to talk about soon.

In reply to @hexa:lossy.network
infinisil: https://github.com/NixOS/nixpkgs/pull/305334#issuecomment-2067069655 can you answer this?

Is there a way I can circumvent the The option <option> is used but not defined error? I am playing around with a silly idea of nix modules to html. You can see the code for the <a> tag module here: https://github.com/djacu/nix2html/blob/main/a.nix

Two attributes I've implemented so far are download and href. If you run the run.sh script, you get an output that should look like this "<a download=new-filename href=#top></a>". But I don't want a user to have to set the download or href attributes every time.

Trying to think of a good solution but coming up empty. Any ideas?