[Duplicated values] error: The option `foo.bar' is defined multiple times while it's expected to be unique

[vic]

Why is Den duplicating configuration values?

I get an error:

error: The option `virtualisation.vmVariant.users.users.vic.shell' is defined multiple times while it's expected to be unique.

Definition values:

- In `/nix/store/3fkd5bqkfigfbmkfaii8bl3q3wgbla7d-source/modules/namespace.nix, via option den.ful.vix.vic.provides.fish.<function body>.nixos': <derivation fish-4.1.2>
- In `/nix/store/3fkd5bqkfigfbmkfaii8bl3q3wgbla7d-source/modules/namespace.nix, via option den.ful.vix.vic.provides.fish.<function body>.nixos': <derivation fish-4.1.2>

Use `lib.mkForce value` or `lib.mkDefault value` to change the priority on any of these definitions.

I have:

den.default.includes = [
  { user, ... }: {
    nixos = { pkgs, ... }: {
      programs.fish.enable = true;
      users.users.${user.userName}.shell = pkgs.fish;
    };
  };
];

I want all my users to use fish shell, that's why I'm using den.default. I have a single host, a single user in it, and the value looks like the exact same thing! What is wrong ?

[vic]

Short answer: Use a function that takes an unambiguous context

Examine the intention of your function, it looks like it wants to provide OS configuration from user data.

According to Den dependencies, the context for that is { OS, fromUser, user, host }, and the following might be sufficiently unambiguous for an OS configuration intent:

{ fromUser, ... }: ...;

Longer answer. Getting to know is the key to most answers.

The error occurs because den.default is a den.lib.parametric.atLeast functor. Your function has arguments { user, ... }, meaning that an atLeast functor (like den.default) will invoke it every time at least user is present in the context.

The same answer applies to any aspect that has functor parametric.atLeast, not only for den.default.

Unfortunately, in Nix, there's no way to distinguish a function taking { user, ... } from one taking { user }, the builtins.functionArgs returns the same argument information for both. That is why Den provides atLeast and exactly combinators that inspect the function arguments against the argument the function is being called with at runtime.

However, to fully understand why this is happening please be sure to read about den dependencies.

TL;DR. You function is being called multiple times because the context is expanding from { OS } to { OS, fromHost, host, user } and { OS, fromUser, user, host }. And your function applies to both of these contexts.

Den expanding contexts? Why are context needed?

An aspect is basically a function that returns a set of configurations. The argument to this function is what Den calls a context; specifically, when the argument is an attribute set, the attribute names and the named arguments a function can take is what decides if a function is invoked or not. This is done by one of Den's atLeast, exactly combinators.

Suppose you have a single hostAspect and a single userAspect. An OS-level configuration, like that for nixos or darwin classes starts by applying the hostAspect with { OS } argument (context).

The hostAspect must then return the whole OS configuration. This is done, by including the results of other function calls into other aspects:

• Calling hostAspect { host } obtains non-dynamic configuration from the hostAspect itself.

  This includes values owned (set directly) in the hostAspect, like hostAspect.nixos.foo = 1;.

  Also, any static values from hostAspect.includes, like:

den.aspects.hostAspect.includes = [ { nixos.foo = 1; } ];

• Calling hostAspect { OS, fromHost, host } obtains the dynamic configuration from functions in hostAspect.includes that might require access to the den.hosts.<system>.<host> data to provide configs.

If the Host has NO users, that is all. Otherwise, we should also retrieve configuration that might be provided for the host OS by its users.

For each host User, the following happens:

• Calling userAspect { user } this is to obtain nixos or darwin class configurations that users can have via their owned or static includes.

• Calling userAspect { OS, fromUser, user, host } gives the User an opportunity to use any dynamic function in userAspect.includes to inspect the host data in order to provide OS class configurations.

• Calling hostAspect { OS, fromHost, host, user } gives the Host the opportunity for any dynamic function in hostAspect.includes to inspect the user data in order to provide OS class configurations.

After all these have been collected we can have the complete OS class configuration.

The host and user data are the attribute-sets defined in den.hosts and its .users.<user>.

OS just marks the configuration intention (since there's also HM and possibly any other user-defined intent).

fromUser and fromHost allow to disambiguate where the direction of config-provisioning.

[vic]

Hm, thanks for your answer, dear sir. However, to me (vic) that feels like somewhat over-complicated, are you willing to accept a PR given that Den is still on its early days ?

From your answer, I believe some contexts are unnecessary, like { OS, fromHost, host} ain't that the same as just { host } ? Functions in hostAspect.includes can be { host }: ... and they can inspect the host data, there's no need for { OS, fromHost ... } stuff ? Well at least for fromHost since you mention there are also other intents beside OS like HM and user-custom intents.

Same for obtaining configurations from users, but maybe you (vic) and me have to think more about this. Thanks for your answer.

EDIT: Using your suggestion { fromUser, ... } worked great! thanks

[vic]

Sure, lets grab a beer over it. I like the idea of it being as minimalist as possible.

[vic]

From your answer, I believe some contexts are unnecessary, like { OS, fromHost, host} ain't that the same as just { host } ? Functions in hostAspect.includes can be { host }: ... and they can inspect the host data, there's no need for { OS, fromHost ... } stuff ? Well at least for fromHost since you mention there are also other intents beside OS like HM and user-custom intents.

Added a test for your use case, fixed duplication bug in #83, removed directional contexts like fromHost and fromUser. Still have to update the docs, but thanks for reporting!

EDIT: I have added more detailed documentation about how the dependency system works, updated with the changes from PR #83. And advice for when duplication can happen on parametric.atLeast functors, as well as how to avoid it.

[vic]

Another home-manager related issue was solved today #87 (comment) but we still have another #89 (related to same aspect sharing) pending. // Update: fixed in #90

[dhnaranjo]

Meta: This role-playing structure for FAQ writing is interesting but a bit hard to follow with one GH user playing both sides.

[vic]

More than role-playing, yesterday I was updating my infra to use Den, and got bitten by that duplication error that was previously reported, so I genuinely asked why. And explaining stuff is also a way to help understanding it, and that's how I (again) discovered I could remove some things that were not essential. So I guess, it is just me being user of my own libraries. When more people actually use Den and report stuff I guess I won't have to post questions myself. Having public question and answer is better since it might help others outside of me.

[Admasnd]

Thank you so much for posting this! I ran into this a few times in the last couple of days while refactoring my aspect containing code and was at my wits end. This really helped in gaining some traction in understanding the core problem.