Sender | Message | Time |
---|---|---|
16 Apr 2024 | ||
Lorenz Leutgeb | * 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 infinisil pointed me at this comment, which helps, but still requires some external source of option names, e.g. I would have to know | 19:35:50 |
infinisil | Lorenz Leutgeb: Ohh actually what should work is to define options in a submodule file, and call the module system using just lib.evalModules { modules = [ ./maubot.nix ]; } . And in the full module, use options.services.maubot = lib.mkOption { type = submodule ./maubot.nix; } | 19:38:42 |
infinisil | * Lorenz Leutgeb: Ohh actually what should work is to define options in a submodule file, and call the module system using just lib.evalModules { modules = [ ./maubot.nix ]; } (and pass that to nixosOptionsDoc . And in the full module, use options.services.maubot = lib.mkOption { type = submodule ./maubot.nix; } | 19:38:55 |
infinisil | * Lorenz Leutgeb: Ohh actually what should work is to define options in a submodule file, and call the module system using just lib.evalModules { modules = [ ./maubot.nix ]; } (and pass that to nixosOptionsDoc ). And in the full module, use options.services.maubot = lib.mkOption { type = submodule ./maubot.nix; } | 19:38:58 |
Lorenz Leutgeb | That seems to split my modules into two files, or put differently, double the number of files (which I have to juggle in my mind), right? I wouldn't like that... | 19:40:57 |
Lorenz Leutgeb | * That seems to split my modules into two files, or put differently, double the number of files which I have to juggle in my mind, right? I wouldn't like that... | 19:41:11 |
infinisil | I don't see another way to avoid having to know about the option location | 19:42:08 |
infinisil | I guess you could hack around it by doing like let maubot = submodule { options = ...; }; in { options._thisIsJustForOptionsRendering = lib.mkOption { type = maubot; }; ... | 19:44:01 |
17 Apr 2024 | ||
nbp joined the room. | 00:29:13 | |
nbp | 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 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 | 01:22:58 |
nbp |
While also providing an answer for what was supposed to be present for the "else" part of the condition. | 01:27:59 |
nbp | Initially I had a mkEmpty property, which served as a way to provide a no-op, and which had to be filtered out. | 01:28:46 |
nbp | * Initially I had a mkEmpty / mkUnused property, which served as a way to provide a no-op, and which had to be filtered out. | 01:29:05 |
nbp | Out of this filtering mechanism came the delayIf / mkIf , by filtering what was rejected by the condition. | 01:29:53 |
nbp | Then came the question of what happens if there are multiple definitions, and if we want to set one more important than the other, and came the mkOrder | 01:30:30 |
nbp | * Then came the question of what happens if there are multiple definitions, and if we want to set one more important than the other, and came the mkOverride | 01:30:35 |
nbp | and way later came mkOrder . | 01:31:57 |
nbp | * Initially I had a mkEmpty / mkUnused / mkNotDef property, which served as a way to provide a no-op, and which had to be filtered out. | 01:41:11 |
nbp | https://www.youtube.com/watch?v=lw7PgphB9qM ibizaman https://www.youtube.com/watch?v=-Bfo3Byjwyg djacu | 09:00:25 |
nbp | {} should be the smallest module possible, if I do not make any mistake. | 09:03:49 |
nbp | djacu: That might be one of the most in-depth module presentation I've seen which does not present mkIf . | 09:44:36 |
nbp | In reply to @infinidoge:matrix.orgThe module system has its own test suite under nixpkgs/lib/tests , the modules directory contains tons of tiny modules, and the modules.sh combine them in various way to check for the expected outcomes. | 10:29:33 |
Robert Hensing (roberth) | In reply to @lorenzleutgeb:matrix.orgSounds 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 | 11:33:32 |
Robert Hensing (roberth) | Would be good to make this kind of logic part of the module system proper. I'd like for something like that to be available in the module system library, and if someone wants to take that code and add tests, that'd be fine with me | 11:36:12 |
Lorenz Leutgeb | In reply to @roberthensing:matrix.orgLooks like you are processing all (many, in my case including all of NixOS) options at once, and are then only filtering the result. This requires some "external data" (=the criteria for the filter). I ended up doing something similar: Couple every path of a file that defines a module with a regex that matches the options I expect to extract from it. Both our solutions are quite easy to implement, but what I was asking for goes a little further, i.e. to let the module system expose such filtering possibility. | 11:42:16 |
Robert Hensing (roberth) | Seems we're asking for the same thing then :) | 11:54:45 |
ibizaman | nbp well, congrats! Because it’s a damn good system indeed! :clap: | 14:00:26 |
ibizaman | In reply to @infinidoge:matrix.orgIn 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. | 14:06:08 |
ibizaman | In reply to @nbp:mozilla.orgIf you prefer a written version of the talk (which is not cut at the end) you can read here :) https://shb.skarabox.com/contracts.html | 14:08:07 |
@infinidoge:matrix.org | In reply to @ibizaman:matrix.orgI more so mean ad-hoc testing of random module things, as opposed to proper module tests, however that is something I should also do | 14:17:03 |