fix: module-level dedup for host-aspects overlap support#468
Conversation
7c327c9 to
2671570
Compare
drupol
left a comment
There was a problem hiding this comment.
This PR fix the issue I described in https://not-a-number.io/2026/evaluating-den-a-dendritic-configuration-framework/ !!!
Looking forward for it...
GG !!!
Named aspects get a key attribute (class@identity) on their collected NixOS modules. The module system deduplicates by key across independent resolve calls, so a user can include an aspect directly AND receive it via host-aspects without duplicate option declarations. Anonymous aspects get stable identities derived from parent chain + positional index (e.g. igloo/<anon>:0) via emitIncludes, replacing the generic <anon> name. This enables correct dedup and improves tracing. Anonymous/synthetic identities are excluded from keying so multiple anonymous includes coexist correctly.
Forward's module-wrapping pattern (_: { imports = [...] }) works for
submodule targets but not for leaf options like environment.sessionVariables
which expect plain attribute values.
Add evalConfig flag to forward: when true, evaluates the source module
in a freeform submodule and sets the resulting config values directly at
the target path instead of wrapping in a module function.
Usage:
den._.forward {
fromClass = _: "variables";
intoPath = _: [ "environment" "sessionVariables" ];
evalConfig = true;
...
};
f3fa9b5 to
5c85b95
Compare
theutz
left a comment
There was a problem hiding this comment.
Oooh I hope this works! 🤞
|
Awesome @sini! Thanks for this! With this working now -and fixing @drupol post- about duplication I believe we can bring back the builtin bidirectionality (that we removed because our legacy core was not able to do this dedup enabled in this fix). What I mean by bidirectionality: That host-aspects correctly contribute user classes We used to do that with this line: https://github.com/vic/den/pull/272/changes#diff-292456ccf182ad0171aa662b32637c8c4591f0d7e471b8bdec8753ba6d09e4efL20 We don't have necessarily to revert that file, but the ideas is that aspects as those defined by drupol's post must work naturally without any extension. |
|
We can chat about this, I'd like to know what you think about this (because I know you have better plans -- capabilities) |
|
Yes. Honestly, I think the pattern you settled on is actually better, we simply need document and educate users about the new host-aspects battery. I have many users I install on my machines who only need slim accounts. |
|
I wonder if having a "isNormalUser"/"isSystemUser"-like toggle might help everyone then when they create new users? So the intentions are explicit for each new user? |
Is that not what the aspect include provides? Perhaps it simply needs a better name. |
Named aspects now get a key attribute (class@identity) on their collected modules. The NixOS module system deduplicates by key across independent resolve calls, so a user can include an aspect directly AND receive it via host-aspects without duplicate option declarations.
Anonymous/synthetic aspects are excluded from keying so multiple anonymous includes coexist correctly.
Also fixes the pre-existing duplication where aspects included by both host and user produced duplicate nixos modules via the default context transition.