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?

nbp: The reason for using submodules is because html attributes can be used in different html elements. So I want a reusable piece of code. The other reason is that I can define how html attributes are called in a standard way using the _out option I defined so everything rolls up nicely using the same logic. No custom logical needed for each html element.

I think I got something working using nullOr with the options inside the html attribute modules. So thanks everyone for your ideas.

Related but different question. I had trouble accessing the isDefined attribute of a submodule option.

For example, I define an option foo whos type is submodule, and with that I define options bar and baz.

At the top level, I can access options.foo.isDefined, but I cannot access options.foo.bar.isDefined. I tried digging around in the options attrset but I couldn't find it. Are the options of a "child" submodule option available to the "parent"?

In reply to @nbp:mozilla.org
isDefined should not be used most of the time, as this is kind of an internal aspect, and it can only be used within the module itself.
Adding an options argument attribute to the submodule would let you query the option tree of the submodule.

Alright I've done something extremely silly and cursed.

https://github.com/djacu/nix2html
nix2html using nixos modules

also featuring the new attrTag type
:D
https://github.com/djacu/nix2html/blob/main/modules/elementChildren.nix

It's barely got any html elements or attributes so far so don't expect the world.