| 27 Mar 2024 |
 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 |
| 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 |
