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)

I'm trying to write nixos config where I can set nixos options from home-manager modules. But I can't get around infinite recursion errors.
I wrote this nixos module, I though this should work, but I'm still getting infinite recursion error, which I don't know how to debug.

{ lib, options, ... }:
with builtins; with lib;

let
  hmModuleBase = with options.home-manager.users.type.nestedTypes.elemType.functor.payload; evalModules {
    inherit class specialArgs;
    modules = modules ++ [{
      options.MrQubo = {
        osConfigs = {
          type = options.raw;
        };
      };
    }];
  };

  evalHmModule = module:
    hmModuleBase.extendModules { modules = [ module ]; };

  isImportableNV = { name, value }:
    (value == "regular" && match ".*\\.nix" name != null) || (value == "directory" && (readDir "${localOverlays}/${name}") ? "default.nix");

  parseNV = { name, value }: rec {
    username = removeSuffix ".nix" name;
    module = evalHmModule ../users/${name};
  };

  userModules = map parseNV (filter isImportableNV (attrsToList (readDir ../users)));

  osConfigs = flatten (map (attrs: attrs.module.MrQubo.osConfigs) userModules);

  hmUsersConfig = {
    home-manager.users = listToAttrs (map (attrs: { name = attrs.username; value = attrs.module; }) userModules);
  };

in mkMerge (osConfigs ++ [ hmUsersConfig ])

Robert Hensing (roberth) thanks for your thoughts here, I figured I'd reply here to save derailing that PR's discussion 😁

I just had a quick look in the repl, and highestPrio seems to be 1500 when an option is undefined such that it is using it's default value.

So we could have an isOptionDefault, but it wouldn't be able to distinguish between a default passed to mkOption and a config definition wrapped using mkOptionDefault.

Maybe that'd be the intended behavior though? 🤔

This also begs the question of how an override priority above 1500 should be handled, though I guess that's off-topic!

Robert Hensing (roberth) thanks for your thoughts here, I figured I'd reply here to save derailing that PR's discussion 😁

An isDefinedExplicitly option attr, true when isDefined, but without using the default.

This can also be achieved with a function from option to bool, by looking at the highestPrio attribute.

I just had a quick look in the repl, and highestPrio seems to be 1500 when an option is undefined such that it is using it's default value.

So we could have an isOptionDefault, but it wouldn't be able to distinguish between a default passed to mkOption and a config definition wrapped using mkOptionDefault.

Maybe that'd be the intended behavior though? 🤔

This also begs the question of how an override priority above 1500 should be handled, though I guess that's off-topic!