Mutual config for host -> standalone home manager?

[HPCesia]

I tried it for den in main and test failed.

{denTest, ...}: {
  flake.tests.bogus = {
    test-host-to-standalone-home = denTest (
      {
        den,
        config,
        pinguHm,
        ...
      }: {
        den.hosts.x86_64-linux.igloo.users = {
          tux = {classes = [];};
          pingu = {classes = ["homeManager"];};
        };
        den.homes.x86_64-linux."tux@igloo" = {};

        den.aspects.igloo.includes = [den.aspects.igloo.policies.to-users];
        den.aspects.igloo.policies.to-users = {
          host,
          user,
          ...
        }: [
          (den.lib.policy.include {
            homeManager.home.preferXdgDirectories = true;
          })
        ];

        den.aspects.tux = {user, ...}: {
          homeManager.home = {
            username = user.name;
            homeDirectory = "/home/${user.name}";
          };
        };

        expr = [
          config.flake.homeConfigurations."tux@igloo".config.home.preferXdgDirectories
          pinguHm.home.preferXdgDirectories
        ];
        expected = [
          true
          true
        ];
      }
    );
  };
}

Check outputs

$ nix flake check
warning: unknown flake output 'tests'
error: builder for '/nix/store/cb2q74aspv7gqpaiwxkpz5ngc4j5c23i-nix-unit-check.drv' failed with exit code 1;
       last 25 log lines:
       >   → 'path:/nix/store/j9scjkalq2ssr649m0c90ry5gk515xzm-source?lastModified=1&narHash=sha256-/GXybz%2Bd8f15E4kBkUWGFZnrbK8PAqXiLmEaDF/nQjU%3D' (1970-01-01)
       > • Updated input 'flake-parts':
       >     'github:hercules-ci/flake-parts/57928607ea566b5db3ad13af0e57e921e6b12381?narHash=sha256-AnYjnFWgS49RlqX7LrC4uA%2BsCCDBj0Ry/WOJ5XWAsa0%3D' (2026-02-02)
       >   → 'path:/nix/store/j5qcw5x2dm0jlffwwymp6yav62l3pdqm-source?lastModified=1&narHash=sha256-AnYjnFWgS49RlqX7LrC4uA%2BsCCDBj0Ry/WOJ5XWAsa0%3D' (1970-01-01)
       > • Updated input 'home-manager':
       >     'github:nix-community/home-manager/0acbd1180697de56724821184ad2c3e6e7202cd7?narHash=sha256-DYS4jIRpRoKOzJjnR/QqEd/MlT4OZZpt8CrBLv%2BcjsE%3D' (2026-02-11)
       >   → 'path:/nix/store/jxpkipflszwa627rb4fj3h2qph6b7f98-source?lastModified=1&narHash=sha256-DYS4jIRpRoKOzJjnR/QqEd/MlT4OZZpt8CrBLv%2BcjsE%3D' (1970-01-01)
       > • Updated input 'import-tree':
       >     'github:vic/import-tree/3c23749d8013ec6daa1d7255057590e9ca726646?narHash=sha256-ZvYKbFib3AEwiNMLsejb/CWs/OL/srFQ8AogkebEPF0%3D' (2025-11-21)
       >   → 'path:/nix/store/057vv882g8mc42r5p8212v0k9vzh1im5-source?lastModified=1&narHash=sha256-ZvYKbFib3AEwiNMLsejb/CWs/OL/srFQ8AogkebEPF0%3D' (1970-01-01)
       > • Updated input 'nix-unit':
       >     'github:nix-community/nix-unit/1c9ab50554eed0b768f9e5b6f646d63c9673f0f7?narHash=sha256-hRADkHjNt41%2BJUHw2EiSkMaL4owL83g5ZppjYUdF/Dc%3D' (2025-11-10)
       >   → 'path:/nix/store/dvh4lxrh9j6n9n6fphwp4mbdpjvvk205-source?lastModified=1&narHash=sha256-hRADkHjNt41%2BJUHw2EiSkMaL4owL83g5ZppjYUdF/Dc%3D' (1970-01-01)
       > • Updated input 'nixpkgs':
       >     'https://releases.nixos.org/nixos/unstable/nixos-26.05pre980183.4bd9165a9165/nixexprs.tar.xz?narHash=sha256-Gk2T0tDDDAs319hp/ak%2BbAIUG5bPMvnNEjPV8CS86Fg%3D' (2026-04-14)
       >   → 'path:/nix/store/m9k87k3yi7z8mmrnvnyajqc28i0mqgg2-source?lastModified=0&narHash=sha256-Gk2T0tDDDAs319hp/ak%2BbAIUG5bPMvnNEjPV8CS86Fg%3D' (1970-01-01)
       > unpacking 'https://github.com/denful/nix-effects/archive/c3c68a45deb892d028711eeff8b80937e30a90dd.zip' into the Git cache...
       > ❌ system-agnostic.bogus.test-host-to-standalone-home
       > /build/nix-8-605819962/expected.nix --- Nix
       > 1 [ false true ]             1 [ true true ]
       >
       >
       >
       > 😢 0/1 successful
       > error: Tests failed
       For full logs, run:
           nix log /nix/store/cb2q74aspv7gqpaiwxkpz5ngc4j5c23i-nix-unit-check.drv

[sini]

Can you confirm if #563 fixes it? If not I'll see if I can reproduce and root cause it.

[sini]

I need to discuss with some others what they think the correct behavior here is -- standalone homes are standalone so I'm not 100% certain if provides /should/ apply to them, though you think they should so thats a valid data point.

[HPCesia]

I need to discuss with some others what they think the correct behavior here is -- standalone homes are standalone so I'm not 100% certain if provides /should/ apply to them, though you think they should so thats a valid data point.

I think provides should at least be applied to standalone homes where the host is specified and managed by den. They already get osConfig arg from it's host, so why not more?

[sini]

I understand -- and probably agree, but the inverse isn't true -- the users to-host provides don't affect the host in the standalone home context.

[fmway]

Mutual provider is about host and user, not home and host. I don't think it's appropriate for home to fire the host-related aspect just using a mutual provider. I'd prefer there a new battery that can share between home and host.

[ppenguin]

I was just bitten by something I think is related, though TBH it's pretty complex to understand enough without diving really deep...

In my new den config I have exclusively standalone HM instances, only on interactive hosts. For this I mirror the aspect concept to have my default user defined as os user and with a common homeManager function, and then host-specific aspects named user@host.

This is den handled with something like:

# users/tux1/host1.nix
den.homes.x86_64-linux."tux1@host1" = {
  aspect = den.aspects."tux1@host1";
};

den.aspects."tux1@host1" = {
includes = [
  den.users.tux1 # I changed the namespace out of aspects because it's cleaner
  den.aspects.user-roles.tux1.dev # this aspect defines a homeManager = { ... }
]

homeManager = ...
...
};

and another for tux1@host2 in users/tux1/host2.nix.

However something very funky happens: the HM config of the wrong host is applied. It seems the collision stems from

den/nix/lib/entities/home.nix

Line 131 in 5df0987

description = strOpt "home description" "home.${config.name}@${config.system}";

, where the user is identified by <user>@<system> instead of <user>@<host>?! Indeed my two hosts are both the same system type.

Still researching... Looks I should open a separate bug report for this...