I've opened a draft PR that does it as an evalModules arg, so it actually works without inf-recursion. I detailed this limitation in the PR description. Any feedback would be greatly appreciated!

https://github.com/NixOS/nixpkgs/pull/333799

I also don't know how much time I can dedicate to it. I had looked at it before when exploring solutions to https://matrix.to/#/!wfudwzqQUiJYJnqfSY:nixos.org/$mVuETvj4dPJNF6ZUdVEVvWmp07L5G3X-6y0bk-NmCP4?via=nixos.org&via=matrix.org&via=nixos.dev, however I came to the conclusion it is an interesting (and useful looking) type, but not a viable solution to the problem we have in nixvim.

I'll attempt to clarify a little in my response to your (very helpful) feedback in #333799.

Thanks again Robert Hensing (roberth) for your feedback and for reminding me of your existing proposals!

I've posted my initial thoughts on github. And further;

Reading through your simple/minimal module eval proposal, I think that's a great solution provided defining config from outside the simple-module type looks the same as defining config for a submodule type; i.e. many of the features you mention arent supported (mkIf for instance) still work, but are handled in the "host" module system before evaluating the resulting configured modules.

Enforcing one module/option per attr level (i.e. no nested options) sounds like a reasonable simplification too.

My main concern is that "perfection" here may be acting as the enemy of "good"; i.e. your proposal is great, but will be much more effort to actually get merged into nixpkgs.

From a different perspective, there's also some simplicity in not reinventing the wheel here, just to support one small feature (config without undefined opts). While we could see this as an opportunity to design a better/faster system, we could also just use the small change for now and consider in the future how it can be improved/replaced. 🤔

Hm, I'm not sure why I was under the impression that the record type was restricted to being flat (and can't contain sub-options or sub-records, I guess). I assume the wildcard type could also be set to something like attrsOf anything to allow recursive merging?

If we can define nested optionalFields and recursively merged wildcards I think it fits nixvim's needs.

Hm, I'm not sure why I was under the impression that the record type was restricted to being flat (and couldn't contain sub-options, sub-records, sub-fields?). I assume the wildcard type could also be set to something like attrsOf anything to allow recursive merging?

If we can define nested optionalFields and recursively merged wildcards I think it fits nixvim's needs.

I'm using modules in my nixos config. For every user in my config I write something like this:

home-manager.users.alice = {
  imports = [ ./hm-common ];
  ...
};

Is it possible to somehow extend home-manager.users. submodule so that it always includes my import, so I don't have to write it for every user?

mr-qubo: yes, by extending the option declaration.

{lib, ...}: {
  home-manage.users = lib.mkOptions {
    type = lib.types.attrsOf (lib.types.submodules [ ./hm-common ]);
  };
}

mr-qubo: yes, by extending the option declaration.

{lib, ...}: {
  options.home-manage.users = lib.mkOptions {
    type = lib.types.attrsOf (lib.types.submodules [ ./hm-common ]);
  };
}

pkgs is not fixed when evaluating imports, in fact nothing that depends on options or config is, including config._module.args.pkgs.

One approach would be to always load the module, but only enable its options on certain systems.

Another approach would be to check system outside of the module eval. E.g. if you're using lib.evalModules you could do:

lib.evalModules {
  modules = [
    ./common.nix
  ]
  ++ lib.optionals (system == "some-system") [
    ./system-specific.nix
  ];
}

(Same applies to wrappers, such as lib.nixosSystem)

Another approach would be to check system outside of the module eval. E.g. if you're using lib.evalModules you could do:

lib.evalModules {
  modules = [
    ./common.nix
  ]
  ++ lib.optionals (system == "some-system") [
    ./system-specific.nix
  ];
}

(Same applies to wrappers, such as lib.nixosSystem)

SebTM

SebTM
pkgs is not fixed when evaluating imports, in fact nothing that depends on options or config is, including config._module.args.pkgs.

One approach would be to always load the module, but only enable its options on certain systems.

Another approach would be to check system outside of the module eval. E.g. if you're using lib.evalModules you could do:

lib.evalModules {
  modules = [
    ./common.nix
  ]
  ++ lib.optionals (system == "some-system") [
    ./system-specific.nix
  ];
}

(Same applies to wrappers, such as lib.nixosSystem)

Anyone know why overriding an option-type's merge function seems to have no effect?

E.g. I have a submodule with a deprecated sub-option. Since the submodule's final value is often fully evaluated (e.g. printed to lua using lib.generators.toLua) I'd like to filter the deprecated option out of the final-merged value to prevent "used but not defined" errors.

I figured I could do something like:

fooType =
  let
    sub = types.submodule ({ config, options, ... }: {
      options.deprecatedOption = mkOption { };
    };
  in
    sub // {
      merge = loc: defs: builtins.removeAttrs (sub.merge loc defs) [
        "deprecatedOption"
      ];
    };

However this doesn't seem to have any effect, deprecatedOption is still present in fooType's final value.

For this specific example, I could use an option's apply function, but I'd like to understand the underlying issue. Implementing it in the type would also be better, as I may use it in several options.

I had a the same issue a few weeks ago when extending types.coercedTo to support deprecation warnings. I wanted to just override the merge attr, however I ended up having to copy the entire coercedTo implementation to get it working...

Seeing as mkOptionType just returns an attrset, I'm confused why overriding the merge attr seemingly doesn't affect how the type is merged in the module system.

Anyone know why overriding an option-type's merge function seems to have no effect?

E.g. I have a submodule with a deprecated sub-option. Since the submodule's final value is often fully evaluated (e.g. printed to lua using lib.generators.toLua) I'd like to filter the deprecated option out of the final-merged value to prevent "used but not defined" errors.

I figured I could do something like:

fooType =
  let
    sub = types.submodule ({ config, options, ... }: {
      options.deprecatedOption = mkOption { };
    });
  in
    sub // {
      merge = loc: defs: builtins.removeAttrs (sub.merge loc defs) [
        "deprecatedOption"
      ];
    };

However this doesn't seem to have any effect, deprecatedOption is still present in fooType's final value.

For this specific example, I could use an option's apply function, but I'd like to understand the underlying issue. Implementing it in the type would also be better, as I may use it in several options.

I had a the same issue a few weeks ago when extending types.coercedTo to support deprecation warnings. I wanted to just override the merge attr, however I ended up having to copy the entire coercedTo implementation to get it working...

Seeing as mkOptionType just returns an attrset, I'm confused why overriding the merge attr seemingly doesn't affect how the type is merged in the module system.

Anyone know why overriding an option-type's merge function seems to have no effect?

E.g. I have a submodule with a deprecated sub-option. Since the submodule's final value is often fully evaluated (e.g. printed to lua using lib.generators.toLua) I'd like to filter the deprecated option out of the final-merged value to prevent "used but not defined" errors.

I figured I could do something like:

fooType =
  let
    sub = types.submodule ({ config, options, ... }: {
      options.deprecatedOption = mkOption { };
    });
  in
    sub // {
      merge = loc: defs: builtins.removeAttrs (sub.merge loc defs) [
        "deprecatedOption"
      ];
    };

However this doesn't seem to have any effect, deprecatedOption is still present in fooType's final value. Calling trace in the overridden merge function doesn't print anything either.

For this specific example, I could use an option's apply function, but I'd like to understand the underlying issue. Implementing it in the type would also be better, as I may use it in several options.

I had a the same issue a few weeks ago when extending types.coercedTo to support deprecation warnings. I wanted to just override the merge attr, however I ended up having to copy the entire coercedTo implementation to get it working...

Seeing as mkOptionType just returns an attrset, I'm confused why overriding the merge attr seemingly doesn't affect how the type is merged in the module system.

In reply to @mattsturg:matrix.org

Another approach would be to check system outside of the module eval. E.g. if you're using lib.evalModules you could do:

lib.evalModules {
  modules = [
    ./common.nix
  ]
  ++ lib.optionals (system == "some-system") [
    ./system-specific.nix
  ];
}

(Same applies to wrappers, such as lib.nixosSystem)