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..

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 small independent module systems to configure nvim/zsh/tmux, and incrementally enable various flags for different flake outputs..

Martin Gaens: I have a home-manager config which is either managed on its own or within NixOS, which I use across 2 different computer. I am using the extraSpecialArgs in flake.nix or home-manager.users.nicolas._module.args when embedded in a NixOS configuration, to set some configuration managed externally.

Note, there is nothing about special args, I might have as well set an option by adding an extra module in homeManager's flake.nix and done the same within the configuration embedded in NixOS.