enum are externally extendable in the module system. This is how desktopManagers / windowManagers are handled. Or why they got added a while back.
The idea of enums is that every module can add the new entry to enable it-self.

type = lib.types.enum [ "this-service-name" ];

makes sense, as opposed to many other languages, because options can be extended by multiple modules. Thus if all providers were to add extra declarations, you could have an option which enumerate all services which could be used as a provider.

Here is an example, where a module declare an enum with no "implementation":
https://github.com/NixOS/nixpkgs/blob/9956df1047bba4e000354f77229b0066d7f364e0/nixos/modules/virtualisation/podman/network-socket.nix#L33-L39

And another module provide an implementation for it:
https://github.com/NixOS/nixpkgs/blob/9956df1047bba4e000354f77229b0066d7f364e0/nixos/modules/virtualisation/podman/network-socket-ghostunnel.nix#L12C50-L18

Could I get some insight into how the module system evaluates a type attrs of differing priorities? I've been working on a little thing that has descending attrsets with reducing priority, in hopes that when they merge some lower attrsets would be erased due to the priority difference but that doesnt seem to be happening. Not sure if I'm operating on a misunderstanding of priorities and merging or not though.

Here's a very minimal example of my issue including a description of what I'm expecting to happen.

let
  lib = import <nixpkgs/lib>;
in lib.evalModules {
  modules = [( { lib, ... }: {
    options = {
      foo = lib.mkOption {
        type = with lib.types; attrs;
      };
    };

    config = lib.mkMerge [
      { foo.bar = lib.mkForce {}; }
      { foo.bar.baz = lib.mkForce {}; }
    ];
  })];
}

You can save the above and use nix eval --file name.nix config or nix repl to view what happens as well, but this is what I get on my system:

nix-repl> :p (import ./test.nix).config
{
  foo = {
    bar = {
      baz = {
        _type = "override";
        content = { };
        priority = 50;
      };
    };
  };
}

From what I understand about both priorities and merging, bar from foo.bar should have a priority of "50" as defined by lib.mkForce, whereas bar from foo.bar.baz should have whatever the default priority is, since foo.bar.baz is the same as foo = { bar = { baz = ...; }; };, which won't have any priority. In that case, I expected foo.bar's priority to overrule foo.bar.baz from merging baz into it, and yet for some reason it does.

The weirdest part is yet to come.. when I switch them around, as in declare foo.bar.baz first and then foo.bar next, it correctly overrides. What's going on here? As far as I know merging is commutative and overriding wouldn't have been affected by it, and yet I'm seeing a sign of it not being the case. This is why I'm first suspecting that I have a misunderstanding regarding how merging works with and without overrides. Does anyone have insight into why this happens?

Oh … how did I missed it …

Properties are evaluated at options, not after, which is why using the value { bar = lib.mkForce {}; } and the value { bar.baz = lib.mkForce {}; } appears in the result, and that we can have one override the other as the update operator defines. Simply because properties are not evaluated, but the value are simply merged.

nix-repl> opt = { options.foo = lib.mkOption { type = lib.types.attrs; }; }
nix-repl> d0 = { foo = lib.mkForce { bar = {}; }; }
nix-repl> d1 = { foo = lib.mkForce { bar.baz = {}; }; }
nix-repl> :p (lib.evalModules { modules = [ opt d0 d1 ]; }).config
{ foo = { bar = { }; }; }
nix-repl> :p (lib.evalModules { modules = [ opt d1 d0 ]; }).config
{ foo = { bar = { baz = { }; }; }; }

Which does not have the priority leaking in the value of the option.

In reply to @frontear:matrix.org
thanks for the response thats honestly somewhat embarrassing that i didnt catch that earlier

Hi all

I've come across a fun problem recently. I maintain a set of modules, and previously I had an option in a submodule, but now I've made it a regular (top-level) option. Per usual with changes like this, I wanted to use mkRenamedOptionModule to alias that option submodule option into the top-level option, but I got a nasty surprise with a cannot find attribute <old attribute name> error message

After doing some digging, I'm assuming this is because submodules sort of strip out the regular option data of their inner values, and only expose the fully evaluated configuration. Am I right here? Is there a good way around this?

Here's a minimum repro:

# repro.nix
let
  lib = import <nixpkgs/lib>;
in

lib.evalModules {
  modules = [
    {
      options = {
        # Create a submodule option
        aSubmodule = lib.mkOption {
          type = lib.types.submodule {
            options = {
              # With an inner option
              someSubmoduleOption = lib.mkEnableOption "something";
            };
          };

          default = { };
        };

        # And a top-level option
        aRegularOption = lib.mkEnableOption "something";
      };
    }

    # Alias them
    (lib.mkRenamedOptionModule [ "aSubmodule" "someSubmoduleOption" ] [ "aRegularOption" ])

    {
      # Test the alias
      # `nix eval --file repro.nix config.aRegularOption`
      aSubmodule.someSubmoduleOption = true;
      # ...but instead you get
      # error: evaluation aborted with the following error message: 'cannot find attribute `aSubmodule.someSubmoduleOption''
    }
  ];
}

Hi all

I've come across a fun problem recently. I maintain a set of modules, and previously I had an option in a submodule, but now I've made it a regular (top-level) option. Per usual with changes like this, I wanted to use mkRenamedOptionModule to alias that submodule option into the top-level option, but I got a nasty surprise with a cannot find attribute <old attribute name> error message

After doing some digging, I'm assuming this is because submodules sort of strip out the regular option data of their inner values, and only expose the fully evaluated configuration. Am I right here? Is there a good way around this?

Here's a minimum repro:

# repro.nix
let
  lib = import <nixpkgs/lib>;
in

lib.evalModules {
  modules = [
    {
      options = {
        # Create a submodule option
        aSubmodule = lib.mkOption {
          type = lib.types.submodule {
            options = {
              # With an inner option
              someSubmoduleOption = lib.mkEnableOption "something";
            };
          };

          default = { };
        };

        # And a top-level option
        aRegularOption = lib.mkEnableOption "something";
      };
    }

    # Alias them
    (lib.mkRenamedOptionModule [ "aSubmodule" "someSubmoduleOption" ] [ "aRegularOption" ])

    {
      # Test the alias
      # `nix eval --file repro.nix config.aRegularOption`
      aSubmodule.someSubmoduleOption = true;
      # ...but instead you get
      # error: evaluation aborted with the following error message: 'cannot find attribute `aSubmodule.someSubmoduleOption''
    }
  ];
}

@getchoo:matrix.org Can't see a way around that problem tbh! Seems like you'll have to manually set it up