| 27 Mar 2024 |
 hexa | I understood config as the implementation section of the module | 23:32:55 |
 Infinidoge | It's... weird, unfortunately. Options are mostly the interface, but with defaults they are somewhat load bearing | 23:34:02 |
| Infinidoge | All default does is assign a value with a priority, the end result here is the same | 23:34:15 |
| Infinidoge | The benefit of it being part of the option is that it can be evaluated without the rest of it for the purpose of documentation and inspection, but in the end it's a modifiable part of the code nonetheless | 23:34:52 |
| Infinidoge | The main issue with doing it the config way is just that it makes that part of it grouped further away, which isn't particularly good | 23:36:20 |
| Infinidoge | It is useful to know if you want to add defaults to other modules though :) | 23:36:32 |
| hexa | agreed | 23:36:33 |
| Infinidoge | In reply to @hexa:lossy.network
bla = mkOption {
defaultText = ''
Something if cond, else unset
'';
} // lib.optionalAttrs (cond) {
default = "bar";
};
Just in case you hadn't tested it yet, this does work by the way | 23:38:04 |
| hexa | I was about to | 23:38:48 |
| Infinidoge | 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 | 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+1) changed their display name from SomeoneSerge (migrating synapse) to SomeoneSerge (void). | 13:23:25 |
|  djacu changed their profile picture. | 23:22:52 |
| 10 Apr 2024 |
|  Olaf Krasicki-Freund 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 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.
| 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 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.
| 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 |
