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

Don't rename modules usually expect the alias-option to not exist; i.e. doRename is responsible for creating the other option ? Even if so, I think that's unrelated.

I've definitely made renames into submodules from outside before (we do this for 50% of nixvim lol), but IIRC making renames out from submodules runs into issues because options.** doesn't exist. Specifically, you run into a _type = "option" object at the submodule-option boundary, options.aSubmodule in the above example.

In nixvim I experimented with resolving the option path recursively, using type.getSubOptions. That was for removal modules, but similar principal.

(This would be (options.aSubmodule._type.getSubOptions options.aSubmodule.loc).someSubmoduleOption in the prior example)

It's also been a while since I looked at the linked code, and IIRC some stuff in that file is broken. Probably the unrelated tryEval hack 😅

Came back to the problem tonight before checking this room again. Seems I came up with a pretty similar solution lol

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

  budgetIsDefined = value: (builtins.tryEval value).success;
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" // {
                # Add some warning stuff
                description = "Alias of `aRegularOption`";
                apply = lib.trace "Obsolete option `aSubmodule.someSubmoduleOption` is used. It was renamed to `aRegularOption`.";
                visible = false;
              };
            };
          };

          default = { };
        };

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

    # Do the actual aliasing
    (
      { config, ... }:
      {
        # We only want to do any of this if the alias option is used
        config = lib.mkIf (budgetIsDefined config.aSubmodule.someSubmoduleOption) {
          aRegularOption = config.aSubmodule.someSubmoduleOption;
        };
      }
    )

    {
      # Now test the alias
      # `nix eval --file repro.nix config.aRegularOption`
      aSubmodule.someSubmoduleOption = true;
    }
  ];
}

The tryEval hack also has a bit of a footgun with type checking though, as incorrect definition errors are eaten up in the same way as when there are no definitions. Don't think there is any way to get more context out of primitive throws though, so this will probably need to be good enough ™️

I really don't recommend using tryEval in this way... It was very situational in nixvim, and even then still probably wasn't the best solution. As you've pointed out, it has plenty of downsides.

I would recommend trying to find the option by recursively walking the "option attr path" (aka loc), checking each attr for lib.isOption and if true, continuing with opt.type.getSubOptions opt.loc.

getOptionRecursive was the part of the file I was hoping you would take inspiration from 😅

Once you have the actual (sub)option you can make use of opt.isDefined with no hacks needed.