!wfudwzqQUiJYJnqfSY:nixos.org

NixOS Module System

82 Members
21 Servers

Load older messages


SenderMessageTime
31 Mar 2024
@technicus:matrix.orgMiles Dyson joined the room.23:06:00
6 Apr 2024
@sammy:cherrykitten.devSammy (It/Its) joined the room.13:05:21
9 Apr 2024
@ss:someonex.netSomeoneSerge (utc+3) changed their display name from SomeoneSerge (migrating synapse) to SomeoneSerge (void).13:23:25
@djacu:matrix.org@djacu:matrix.org changed their profile picture.23:22:52
10 Apr 2024
@olafkfreund:matrix.org@olafkfreund:matrix.org left the room.08:31:16
11 Apr 2024
@princemachiavelli:matrix.orgprincemachiavelli joined the room.17:33:46
@pxc:matrix.orgpxc joined the room.18:10:56
16 Apr 2024
@lorenzleutgeb:matrix.orgLorenz Leutgeb joined the room.19:34:05
@lorenzleutgeb:matrix.orgLorenz 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
@lorenzleutgeb:matrix.orgLorenz 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:matrix.orginfinisil 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:matrix.orginfinisil * 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:matrix.orginfinisil * 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
@lorenzleutgeb:matrix.orgLorenz LeutgebThat 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
@lorenzleutgeb:matrix.orgLorenz 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:matrix.orginfinisilI don't see another way to avoid having to know about the option location19:42:08
@infinisil:matrix.orginfinisil 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:mozilla.orgnbp joined the room.00:29:13
@nbp:mozilla.orgnbp

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 configuration.nix file as-is, and extend it in a way which felt natural. At the time we had only /etc/nixos/configuration.nix and one file containing all the options declarations as part of NixOS.

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 delayIf (mkIf), Adding types as a way to refine the default merging function.

01:22:58
@nbp:mozilla.orgnbp

delayIf came from wanting to avoid to repeat my-self for each option that I wanted to set conditionally.

{
  a = if cond then ... else ???;
  b = if cond then ... else ???;
  c = if cond then ... else ???;
}

While also providing an answer for what was supposed to be present for the "else" part of the condition.

01:27:59
@nbp:mozilla.orgnbp 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
@nbp:mozilla.orgnbp * Initially I had a mkEmpty / mkUnused property, which served as a way to provide a no-op, and which had to be filtered out. 01:29:05
@nbp:mozilla.orgnbp Out of this filtering mechanism came the delayIf / mkIf, by filtering what was rejected by the condition. 01:29:53
@nbp:mozilla.orgnbp Then came the question of what happens if there are multiple definitions, and if we want to set one more important than the other, and came the mkOrder 01:30:30
@nbp:mozilla.orgnbp * Then came the question of what happens if there are multiple definitions, and if we want to set one more important than the other, and came the mkOverride 01:30:35
@nbp:mozilla.orgnbp and way later came mkOrder. 01:31:57
@nbp:mozilla.orgnbp * Initially I had a mkEmpty / mkUnused / mkNotDef property, which served as a way to provide a no-op, and which had to be filtered out. 01:41:11
@nbp:mozilla.orgnbp https://www.youtube.com/watch?v=lw7PgphB9qM ibizaman
https://www.youtube.com/watch?v=-Bfo3Byjwyg djacu
09:00:25
@nbp:mozilla.orgnbp {} should be the smallest module possible, if I do not make any mistake. 09:03:49
@nbp:mozilla.orgnbp djacu: That might be one of the most in-depth module presentation I've seen which does not present mkIf. 09:44:36

Show newer messages


Back to Room ListRoom Version: 10