So, hi! I'm working on a thing to let me write home-manager homes that can be either used independently or attached to NixOS systems... my homes look like some attrset of { modules = [ ... ]; args = { ... }; }, args being some specialArgs provided to home-manager normally ...

... attaching the home modules to a home-manager NixOS home is fairly straightforward, I can write some code that looks a little like this to generate some NixOS modules that put everything where I want it to go ...

map (module: {
  home-manager.users.${username} = module;
}) home.modules;

unfortunately, not so with setting the special args. Home-manager's NixOS module has a way to do this: home-manager.extraSpecialArgs, but it's not per-user so if I attach multiple homes that would cause issues. I tried setting _module.args but (1) was getting infinite recursion when I tried to use any of the new args, and (2) that is a little different from how home-manager standalone is consuming the args, and I'd prefer to avoid inconsistencies if at all possible...

...I wondered about merging in some options that defined more specialArgs, since as in NixOS a home-manager module is a submoduleWith and I know those can be merged. Unfortunately, it's actually an attrsOf submoduleWith, so I can't merge into home-manager.users.${username} or I get this "would be a parent of the following options but its type does not support nested options" error...

...the comment above that seems to suggest that's because it w

So, hi! I'm working on a thing to let me write home-manager homes that can be either used independently or attached to NixOS systems... my homes look like some attrset of { modules = [ ... ]; args = { ... }; }, args being some specialArgs provided to home-manager normally ...

... attaching the home modules to a home-manager NixOS home is fairly straightforward, I can write some code that looks a little like this to generate some NixOS modules that put everything where I want it to go ...

map (module: {
  home-manager.users.${username} = module;
}) home.modules;

unfortunately, not so with setting the special args. Home-manager's NixOS module has a way to do this: home-manager.extraSpecialArgs, but it's not per-user so if I attach multiple homes that would cause issues. I tried setting _module.args but (1) was getting infinite recursion when I tried to use any of the new args, and (2) that is a little different from how home-manager standalone is consuming the args, and I'd prefer to avoid inconsistencies if at all possible...

...I wondered about merging in some options that defined more specialArgs, since as in NixOS a home-manager module is a submoduleWith and I know those can be merged. Unfortunately, it's actually an attrsOf submoduleWith, so I can't merge into home-manager.users.${username} or I get this "would be a parent of the following options but its type does not support nested options" error...

...the comment above that seems to suggest that's because it would be ambiguous

https://github.com/NixOS/nixpkgs/blob/f880c595eafbd35ed066f0a8097409cb79188798/lib/modules.nix#L822

          # Raw options can only be merged into submodules. Merging into
          # attrsets might be nice, but ambiguous. Suppose we have
          # attrset as a `attrsOf submodule`. User declares option
          # attrset.foo.bar, this could mean:
          #  a. option `bar` is only available in `attrset.foo`
          #  b. option `foo.bar` is available in all `attrset.*`
          #  c. reject and require "<name>" as a reminder that it behaves like (b).
          #  d. magically combine (a) and (c).
          # All of the above are merely syntax sugar though.

I want option A here I think - but I'm not sure what it's syntax sugar for... does anyone know what this is syntax sugar for and/or does anyone else have a pointer to how I might be able to set these specialArgs for only a single home-manager user

https://github.com/NixOS/nixpkgs/blob/f880c595eafbd35ed066f0a8097409cb79188798/lib/modules.nix#L822

          # Raw options can only be merged into submodules. Merging into
          # attrsets might be nice, but ambiguous. Suppose we have
          # attrset as a `attrsOf submodule`. User declares option
          # attrset.foo.bar, this could mean:
          #  a. option `bar` is only available in `attrset.foo`
          #  b. option `foo.bar` is available in all `attrset.*`
          #  c. reject and require "<name>" as a reminder that it behaves like (b).
          #  d. magically combine (a) and (c).
          # All of the above are merely syntax sugar though.

I want option A here I think - but I'm not sure what it's syntax sugar for... does anyone know what this is syntax sugar for and/or does anyone else have a pointer to how I might be able to set these specialArgs for only a single home-manager user?

Apologies if I missed anything, but why do you need to set specialArgs? Generally, they should be avoided at all costs as they cannot be configured from within modules* and they make any modules that rely on them very not-portable.

If you just want extra module args, you can usually use the _module.args option. "Special" args are only needed when defining imports.

If you just need to pass some value from another scope into a modules (e.g. to access inputs from a flake) then you can use lexical scoping (define the module within a file that has access to what you need) or pass in extra args using something like lib.modules.importApply or flake-part's fancy moduleWithSystem function, if you're using flake-parts.

I wondered about merging in some options

You could always declare these options within the submodule rather than merging them in by declaring them in the outer module eval. If you do this in a module that is defined within a file with access to the args you want, then you shouldn't need to do anything fancy. That said, these wouldn't be "special" because they'd be configured within the submodule eval, but that's no different to a merged-in option declaration.

* it is the fact that these args are defined outside of the module system eval that makes them "special".

If you want an option to be available for a single user, this should be as simple as:

  config.home-manager.users.${username} = module;

Where the module declares the option you want to see available for this user only.

Submodules are literally modules, following the same shortcuts that config is the default attribute when not specified. Thus specifying options and config in the submodule should merge it like any other module.

I think I maybe misphrased my question, sorry, this was supposed to all be about getting args into the module... the tangent with the options was one way I'd tried to do this

i.e. literally taking another options.home-manager.users.${username} = mkOption { type = subModuleWith { specialArgs = ... }; }; and having them merged together by the module system

when I tried setting home-manager.users.${username}._module.args, if I tried to use the arg in another module I was getting an infinite recursion error however when I tried home-manager.extraSpecialArgs I was able to use the arg - this led me to conclude that I needed args outside the module system, however if I understand you right I don't if they aren't being used by imports(?)

my example is kinda convoluted at the moment - but I'll see if I can get something more minimal to send here...

Without getting too much into the weeds, infinite recursion can show up for a number of reasons. Not just defining imports via a config value (such as non-special args).

For example, trying to use an arg that doesn't exist usually shows up as infinite recursion too. E.g. if you were defining or using args in mismatched module evals.

As for "merging in" special args; this isn't really possible because the whole point of special args is that they aren't defined by the module system.

Is there a reason you need different args per user instead of using home-manager's shared extraSpecialArgs NixOS option?

In reply to @mattsturg:matrix.org

Without getting too much into the weeds, infinite recursion can show up for a number of reasons. Not just defining imports via a config value (such as non-special args).

For example, trying to use an arg that doesn't exist usually shows up as infinite recursion too. E.g. if you were defining or using args in mismatched module evals.

As for "merging in" special args; this isn't really possible because the whole point of special args is that they aren't defined by the module system.

Is there a reason you need different args per user instead of using home-manager's shared extraSpecialArgs NixOS option?

For example, trying to use an arg that doesn't exist usually shows up as infinite recursion too. E.g. if you were defining or using args in mismatched module evals.

Yeah, I've definitely seen this... the way I'm doing it at the moment is generating a list of modules for my NixOS config, including both modules that set home-manager user modules up and modules that set home-manager.users.${username}._module.args ... the symptoms are the same as if I don't set them though... I guess maybe they are in mismatched module evals (how would I know?)

As for "merging in" special args; this isn't really possible because the whole point of special args is that they aren't defined by the module system.

gotcha - yeah... the special args are defined in NixOS and I have what I want them to be for the homes in NixOS. If I could merge in a different type for each attr of the attrsOf I think I could do it, since as I could merge in another submodule that has the specialArgs I want ... unfortunately it's pretty much all or nothing there

Is there a reason you need different args per user instead of using home-manager's shared NixOS option?

it's a pretty artificial constraint, but I'm not making the structure for homes themselves - so I can't guarentee that there aren't conflicting home args set in different homes ... I'm trying to make a thing that can be used to take standalone home-manager homes and put them in nixos systems - and the individual standalone home-manager home spec I have here doesn't share special args... what I'm trying to do is mostly plumbing, I hadn't considered seeing if I could get the home spec modified to better fit this case (or just, you know, ban setting these to different things)

I'd strongly consider discouraging specialArgs in general. There are other ways to pass args into modules without needing to add "special" args to the entire configuration (module eval).

I appreciate specialArgs can be convenient and are often used in examples and personal configs where portability isn't an issue, but it is much better to apply these "external" values directly into the individual modules that need them.

E.g. this module uses inputs.self via lexical scoping; no specialArgs needed:

{
  outputs = inputs: {
    nixosModules = {
      default = {
        # import all the other modules in this flake:
        imports = builtins.attrValues (builtins.removeAttrs inputs.self.nixosModules [ "default" ]);
      };
    };
  };
}

This one has access to inputs via an extra set of args applied before the module:

# flake.nix
{
  outputs =
    inputs:
    let
      inherit (inputs.nixpkgs) lib;
      inherit (lib.modules) importApply;
    in
    {
      nixosModules = {
        someModuleWithInputs = importApply ./module.nix { inherit inputs; };
      };
    };
}

# module.nix
{ inputs }@appliedArgs:
{ lib, config, ... }@moduleArgs:
{
  imports = [
    inputs.foo.nixosModules.default
  ];
}

Sorry if I was dismissive before, I'm fresh with coffee now! 😁

including both modules that set home-manager user modules up and modules that set home-manager.users.${username}._module.args ... the symptoms are the same as if I don't set them though... I guess maybe they are in mismatched module evals

Well, in that example the { _module.args } bit is a home-manager user module. So assuming you're defining it for the same user that has modules using the args, they should be present.

(how would I know?)

I would try a simple example; define two modules for the same user. One defining module args, the other trying to use them in some non-recursive way.

As for "merging in" special args; this isn't really possible because the whole point of special args is that they aren't defined by the module system.

I was over-simplifying when I said this; because the submodule with the special args you're setting is a separate module eval, you are still defining them outside that module eval. However IDK if the submodule type supports type-merging them. e.g. if you declared a duplicate option with additional special args in its submoduleWith type.

I.e. in some cases you can declare the same option twice, and the module system will merge those declarations (not definitions!). This is kinda black magic though, and only supports merging certain aspects of options. Most of the time you'll get an "option declared multiple times" error.

If you really do need this and none of the alternative approaches I suggested are sufficient, I would suggest sending a PR to home-manager which adds a "per-user" extraSpecialArgs option.

The existing extraSpecialArgs option is declared here, and used here.

Such an option might look like:

userSpecialArgs = lib.mkOption {
  type = types.attrsOf types.attrs;
      default = { };
      example = lib.literalExpression "{ fred = { inherit freds-inputs; }; }";
      description = ''
        Per-user extra `specialArgs` passed to Home Manager, only for the specified users.
        See also {option}`home-manager.extraSpecialArgs`.
      '';
};

cc Austin Horstman

Feel free to ping me in any relevant PRs.

Hello!

Given I am making a custom module system, and I have set _module.args.foobar = "something".
I'm trying to use eval.extendModules and override the _module.args.foobar with a value with higher priority (by 1).
In my case I cannot just hardcode another priority because the extendModules might be called multiple times, thus I need to override foobar multiple times.
I tried finding the highestPrio field of _module.args.foobar using eval.options._module.args.foobar.highestPrio but it's saying that foobar doesn't exist here.
Am I missing something?

Hello!

Given I am making a custom module system, and I have set _module.args.foobar = "something".
I'm trying to use eval.extendModules and override the _module.args.foobar with a value with higher priority (by 1).
In my case I cannot just hardcode another priority because the extendModules might be called multiple times, thus I need to override foobar multiple times.
I tried finding the highestPrio field of _module.args.foobar using eval.options._module.args.foobar.highestPrio but it's saying that foobar doesn't exist here.
Am I missing something?

Hello!

Given I am making a custom module system, and I have set _module.args.foobar = "something".
I'm trying to use eval.extendModules and override the _module.args.foobar with a value with higher priority (by 1).
In my case I cannot just hardcode another priority because the extendModules might be called multiple times, thus I need to override foobar multiple times.
Currently I do this by keeping track of the previous priority manually out of band (I re-implemented a kind of extendModules myself before discovering that it exists 👀), but I recently discovered highestPrio which would allow me to find the previous prio directly on the last module eval.

I tried finding the highestPrio field of _module.args.foobar using eval.options._module.args.foobar.highestPrio but it's saying that foobar doesn't exist here.

Am I missing something?

Hello!

I am making a custom module system, and I have set _module.args.foobar = mkOverride 1000 "something".
I'm trying to use eval.extendModules and override the _module.args.foobar with a value with higher priority (by 1).
In my case I cannot just hardcode 999 here because the extendModules might be called multiple times, thus I need to override foobar multiple times with priority 998 then 997, etc...
Currently I do this by keeping track of the previous priority manually out of band (I re-implemented a kind of extendModules myself before discovering that it exists 👀), but I recently discovered highestPrio which would allow me to find the previous prio directly on the last module eval.

I tried finding the highestPrio field of _module.args.foobar using eval.options._module.args.foobar.highestPrio but it's saying that foobar doesn't exist here.

Am I missing something?

Hello!

I am making a custom module system, and I have set _module.args.foobar = mkOverride 1000 "something".
I'm trying to use eval.extendModules and override the _module.args.foobar with a value with higher priority (by 1).
In my case I cannot just hardcode 999 here because the extendModules might be called multiple times, thus I need to override foobar multiple times with priority 998 then 997, etc...
Currently I do this by keeping track of the previous priority manually out of band (I re-implemented a kind of extendModules myself before discovering that it exists 👀), but I recently discovered highestPrio which would allow me to find the previous prio directly on the last module eval.

I tried finding the highestPrio field of _module.args.foobar using eval.options._module.args.foobar.highestPrio but it's saying that foobar doesn't exist here.

What am I missing? 🤔

Hello!

I am making a custom module system, and I have set _module.args.foobar = mkOverride 1000 "something".
I'm trying to use eval.extendModules and override the _module.args.foobar with a value with higher priority (by 1).
In my case I cannot just hardcode 999 here because the extendModules might be called multiple times, thus I need to override foobar multiple times with priority 998 then 997, etc...
Currently I do this by keeping track of the previous priority manually out of band (I re-implemented a kind of extendModules myself before discovering that it exists 👀), but I recently discovered highestPrio which would allow me to find the previous prio directly on the last module eval.

I tried finding the highestPrio field of _module.args.foobar using eval.options._module.args.foobar.highestPrio but it's saying that foobar doesn't exist here.
It kind of make sense to me because foobar is not an option, it's really part of the config at this point, but then is there still a way to access the priority?

What am I missing? 🤔

Hello!

I am making a custom module system, and I have set _module.args.foobar = mkOverride 1000 "something".
I'm trying to use eval.extendModules and override the _module.args.foobar with a value with higher priority (by 1).
In my case I cannot just hardcode 999 here because the extendModules might be called multiple times, thus I need to override foobar multiple times with priority 998 then 997, etc...
Currently I do this by keeping track of the previous priority manually out of band (I re-implemented a kind of extendModules myself before discovering that it exists 👀), but I recently discovered highestPrio which would allow me to find the previous prio directly on the last module eval.

I tried finding the highestPrio field of _module.args.foobar using eval.options._module.args.foobar.highestPrio but it's saying that foobar doesn't exist here.
It kind of make sense to me because foobar is not an option, it's really part of the config at this point, but then is there still a way to access the priority from eval?

What am I missing? 🤔

Hello!

I am making a custom module system, and I have set _module.args.foobar = mkOverride 1000 "something".
I'm trying to use eval.extendModules and override the _module.args.foobar with a value with higher priority (by 1).
In my case I cannot just hardcode 999 here because the extendModules might be called multiple times, thus I need to override foobar multiple times with priority 998 then 997, etc...
Currently I do this by keeping track of the previous priority manually out of band (I re-implemented a kind of extendModules myself before discovering that it exists 👀), but I recently discovered highestPrio which would allow me to find the previous prio directly on the last module eval.

I tried finding the highestPrio field of _module.args.foobar using eval.options._module.args.foobar.highestPrio but it's saying that foobar doesn't exist here.
It kind of make sense to me because foobar is not an option, it's really part of the config at this point, but then is there still a way to access the priority from module eval?

What am I missing? 🤔

Options have highestPrio (and other) attributes, however in this case _module.args is the option, not _module.args.foobar.

foobar is an attribute of _module.args' value.

You may find it helpful to inspect this in nix repl.

In this case you can use lib.modules.mergeAttrDefinitionsWithPrio to get the priorities of each attr of _module.args; there's an example of this in the nixos/modules/misc/nixpkgs.nix module.

Awesome. That sounds more idiomatic!

Just a general design titbit: extendModules is more efficient when you don't read anything from the extended configuration.

Due to laziness, extended module evals don't actually need to be fully evaluated, so if you only read from the "final" extended configuration, then you don't need to also spend time evaluating the other ones.

Yes, I'm quite happy with what I managed to do ✨
Basically I made a system where I can easily eval an initial config, then call theconfig.lib.extendWith somemodule that returns a new config with the somemodule applied on top.
This module can access the previous config if it needs it, and the extendWith can be done on any config 'instance' ❤️
https://github.com/bew/dotfiles/blob/main/nix/kit-system/tests.nix if you want to take a look

I use this in my dotfiles to make mini module systems to configure nvim/zsh/tmux, and incrementally enable various flags for different flake outputs..