Sender | Message | Time |
---|---|---|
27 Mar 2024 | ||
hexa | I was about to | 23:38:48 |
@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 | 23:39:48 |
28 Mar 2024 | ||
@adam:robins.wtf | build a nixosTest? | 13:46:45 |
@infinidoge:matrix.org | This is more about the module system itself as opposed to NixOS, so a NixOS test would be a bit overkill | 15:56:53 |
@adam:robins.wtf | well if you write a nixosTest, then you can load it into the repl within nixpkgs without having to use your flake | 17:01:43 |
@adam:robins.wtf | saves time of updating the flake input and copying a bunch to the store | 17:02:30 |
@adam:robins.wtf | (or use existing test while developing) | 17:06:31 |
29 Mar 2024 | ||
SebTM joined the room. | 04:22:55 | |
31 Mar 2024 | ||
chadac | Is there anything that influenced the design of the module system? After playing around with modules for a while I'm amazed I haven't been using something like this earlier, it seems so natural for designing templates. | 03:56:07 |
Miles Dyson joined the room. | 23:06:00 | |
6 Apr 2024 | ||
Sammy (It/Its) joined the room. | 13:05:21 | |
9 Apr 2024 | ||
SomeoneSerge (utc+3) changed their display name from SomeoneSerge (migrating synapse) to SomeoneSerge (void). | 13:23:25 | |
@djacu:matrix.org changed their profile picture. | 23:22:52 | |
10 Apr 2024 | ||
@olafkfreund:matrix.org left the room. | 08:31:16 | |
11 Apr 2024 | ||
princemachiavelli joined the room. | 17:33:46 | |
pxc joined the room. | 18:10:56 | |
16 Apr 2024 | ||
Lorenz Leutgeb joined the room. | 19:34:05 | |
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:27 |
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 |