| 27 Mar 2024 |
Migrated to @infinidoge:inx.moe | It is useful to know if you want to add defaults to other modules though :) | 23:36:32 |
hexa | agreed | 23:36:33 |
Migrated to @infinidoge:inx.moe | 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 |
Migrated to @infinidoge:inx.moe | 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 |
Migrated to @infinidoge:inx.moe | 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+U[-12,12]) 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 |
| 17 Apr 2024 |
| nbp joined the room. | 00:29:13 |