Managing user-specific home manager configs for the same aspect

[AnonymousRand]

Hi, pretty new to den here, coming from a more traditional dendritic setup with just flake-parts. I've been grappling with an architectural problem with dendritic pattern in general, and I'm really curious if den has an elegant solution for this that I haven't been able to see:

Say alice and bob are two users with different, and long, home manager configs for a feature like Firefox—perhaps alice wants declarative configs and bob wants to xdg.configFile raw dotfiles. How should you write den.aspects.firefox to accommodate this? It almost feels like the "reusable aspects" idea of den (and dendritic pattern in general) sort of breaks down in this case.

Currently what I have going is to just provide a very minimal and unopinionated den.aspects.firefox that basically does nothing but

den.aspects.firefox = {
  homeManager = {
    programs.firefox.enable = true;
  };
};

Then, alice and bob respectively get sub-aspects that include this:

den.aspects.firefox.alice = {
  includes = [ den.aspects.firefox ];
  # alice's own home manager config ...
}

and

den.aspects.firefox.bob = {
  includes = [ den.aspects.firefox ];
  # bob's own home manager config ...
}

(or perhaps den.aspects.alice.firefox and den.aspects.bob.firefox instead? although this feels less feature-oriented). Then, alice's user aspect includes den.aspects.firefox.alice and bob's includes den.aspects.firefox.bob. (In my original dendritic setup without den, these subaspects were instead just private, regular nixos module that alice and bob would import by relative path.)

However, this still feels pretty inelegant and somewhat hard to manage as new users come along (e.g. the subaspect having to include its "parent" aspect feels kind of cumbersome). Is there a nicer way to make this work? For example, would setting custom options within the user aspect to store configs and just referencing that in each aspect be more idiomatic?

(Apologies if I'm missing something obvious. I wasn't able to find many repos on github that had vastly differing home manager configs for each user, so help would be greatly appreciated!)

[yhay81]

Your current approach does not mean the aspect model has broken down; it means “Firefox” and “Alice's choice of Firefox policy” are two different concerns.

Den automatically creates an aspect for each user entity (den.aspects.alice, den.aspects.bob). Those user aspects are natural composition roots for user-specific choices. I would keep reusable Firefox implementations feature-oriented, but name them by behavior rather than by user:

{ den, ... }:
{
  # Reusable invariant, only if there really is one.
  den.aspects.firefox.base.homeManager = {
    programs.firefox.enable = true;
  };

  den.aspects.firefox.declarative = {
    includes = [ den.aspects.firefox.base ];

    homeManager = {
      # programs.firefox.profiles / policies / extensions / ...
    };
  };

  den.aspects.firefox.raw-dotfiles = {
    includes = [ den.aspects.firefox.base ];

    homeManager = {
      # xdg.configFile."..." = { source = ...; };
    };
  };

  den.aspects.alice.includes = [
    den.aspects.firefox.declarative
  ];

  den.aspects.bob.includes = [
    den.aspects.firefox.raw-dotfiles
  ];
}

This leaves one line to change when adding a user, while the large implementations remain reusable and live under the Firefox feature tree. The dependency on base is not a workaround; includes is exactly Den's aspect-composition edge. If the only shared line is programs.firefox.enable = true and the profiles otherwise have nothing in common, it is also fine to remove base and put that line in each profile—do not invent an abstraction with no useful invariant.

For configuration that is truly unique and will never be reused, put it directly on the automatically created user aspect instead:

den.aspects.alice.homeManager.imports = [
  ./users/alice/firefox.nix
];

den.aspects.bob.homeManager.imports = [
  ./users/bob/firefox.nix
];

That is still aspect-oriented: the user entity aspect owns the user-specific policy, while the imported file merely keeps a long Home Manager module manageable. Den's example explicitly uses den.aspects.alice for Alice's own Home Manager configuration and recommends local/own modules for private one-shot aspects.

A third, data-driven option is useful only if you have many users choosing from the same small set of profiles: add a typed user-schema field such as firefoxProfile = "declarative" and have a parametric Firefox aspect select the corresponding profile using the user context. I would not start there for two users—the explicit includes above are easier to read and produce better errors.

So my rule of thumb would be:

• reusable implementation → firefox.declarative, firefox.raw-dotfiles;
• per-user selection/composition → den.aspects.alice.includes;
• genuinely one-off details → the user's own homeManager module;
• shared defaults → a small firefox.base only when it contains real shared behavior.

This matches Den's documented split: entities describe what exists, aspects describe behavior, and each user entity automatically gets an aspect that can compose other aspects.

References:

• Configure Aspects — automatic entity aspects, includes, and provides
• Entities & Schema — users are host-scoped entities with their own aspect
• Example Alice aspect — user-owned Home Manager config and private includes

[AnonymousRand]

Thanks for pointing me to the example Alice aspect for the private modules. I've also been trying out creating a namespace for each user:

# modules/users/alice.nix

{ inputs, ... }: {
  imports = [
    (inputs.den.namespace "alice" false)
  ];
  
  den.aspects.alice = { ... };
}

Then I can store alice's private extensions of den.aspects.<aspect> in alice.<aspect> instead of importing them as regular nix modules. This lets me still put everything under an aspect and hence access things like quirks, and I also think it's a bit better semantically than using subaspects like den.aspects.<aspect>.alice.

(Although the fact that you can't declare namespaces inside schemas makes me wonder if this idea of namespaces "belonging" to a specific entity is not really what they are designed for…)

[yhay81]

That is a reasonable local organization, with one important semantic distinction: the namespace does not actually belong to the alice entity. It is an independent aspect library named alice; false only means it is not exported as flake.denful.alice.

The public namespace guide describes exactly that model: den.ful.<name> is a scoped aspect library, and its aspects are consumed by including them from den.aspects.*. The test suite also explicitly checks that namespace aspects are independent from den.aspects.

So I would wire the relationship explicitly and keep the automatic entity aspect as the composition root:

{ den, alice, bob, ... }: {
  den.aspects.alice.includes = [ alice.firefox ];
  den.aspects.bob.includes = [ bob.firefox ];
}

Then your reading is sound:

• alice.firefox is Alice's private/local library implementation;
• den.aspects.alice is still the user entity aspect that selects it;
• namespace features such as nested provides, quirks/schema resolution, and parametric aspects continue to work inside alice.

The fact that inputs.den.namespace cannot be declared dynamically inside an entity schema follows from this separation: creating a namespace is a top-level module import which creates an independent option/aspect tree. A schema describes entity fields; it does not instantiate a new aspect library for every entity value. (There are internal tests for namespace.schema.*, but that is defining schema entries inside an already-created namespace, not making a namespace owned by each user.)

For two known users, a local namespace per user is perfectly defensible if the separation makes the tree clearer. The trade-offs are that each new user needs an explicit namespace import, generic tooling will not infer that namespace alice corresponds to entity alice, and reusable pieces can become accidentally duplicated across the user libraries. I would therefore keep generally reusable implementations in a behavior/team namespace and reserve alice.* for genuinely private extensions.

One final caveat: false prevents publishing the namespace as a flake output; it is not a secrecy boundary. Do not put credentials in those Nix modules, because evaluated source can still enter the Nix store.