| 27 Mar 2024 |
 @infinidoge:matrix.org | I think that would work | 23:27:14 |
| @infinidoge:matrix.org | Might need parenthesis, but even then | 23:27:23 |
 hexa | 🙂 | 23:27:35 |
| @infinidoge:matrix.org | If it doesn't work, you can definitely do it through config though | 23:28:44 |
| @infinidoge:matrix.org | config.bla = lib.mkIf cond (lib.mkDefault "value");
| 23:29:08 |
| hexa | yeah, but that's not really discoverable | 23:29:36 |
| hexa | * bla = mkOption {
defaultText = ''
Something if cond, else unset
'';
} // lib.optionalAttrs (cond) {
default = "bar";
};
| 23:30:03 |
| hexa | update the example with defaultText | 23:30:12 |
| @infinidoge:matrix.org | You're already gonna need to use the documentation text override, so I don't think it would really affect the discoverability that much | 23:30:19 |
| hexa | that was always going to be the case | 23:30:32 |
| hexa | but defaultText makes the condition discoverable | 23:30:39 |
| hexa | as opposed to hiding it in the implementation | 23:30:47 |
| @infinidoge:matrix.org | My example was just how the default part could be done, wasn't a self-contained example | 23:31:58 |
| hexa | I understood config as the implementation section of the module | 23:32:55 |
| @infinidoge:matrix.org | It's... weird, unfortunately. Options are mostly the interface, but with defaults they are somewhat load bearing | 23:34:02 |
| @infinidoge:matrix.org | All default does is assign a value with a priority, the end result here is the same | 23:34:15 |
| @infinidoge:matrix.org | 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:matrix.org | 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:matrix.org | It is useful to know if you want to add defaults to other modules though :) | 23:36:32 |
| hexa | agreed | 23:36:33 |
| @infinidoge:matrix.org | 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: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 |
