provides.<username> does not work when username is literal "user"

[wtf9880]

Hi, I was struggling with my Nix config to find out why provides.<username> wasn't working as expected based on this guide. After writing a test, I discovered that the problem was that my primary username on the host was literally named user.

{ denTest, ... }:
{
  flake.tests.mybug = {
    test-something = denTest (
      { den, igloo, ... }:
      {
        den.hosts.x86_64-linux.igloo.users.user = { };


        den.aspects.igloo = {
          provides.user = {
            nixos.networking.hostName = "myhostname";
          };
        };

        expr = igloo.networking.hostName;
        expected = "myhostname";
      }
    );
  };
}

results:

❌ test-something
/tmp/nix-22817-2009092312/expected.nix --- Nix
1 "nixos"                    1 "myhostname"



😢 0/1 successful
error: Tests failed

but when i change user to tux the test passes successfully

[sini]

That's because user is a reserved class keyword.

[wtf9880]

i don't know Nix at advanced level but can we make double-quoted strings work for this situation as a workaround? for example den.aspects.foo.provides."<username>".nixos...?

[sini]

There is no difference between the two.

[wtf9880]

oh thanks i didn't know that, i thought maybe they are different things in Nix. seems nothing we can do about it so i will change my username. can we add a warning when username in den.hosts.x86_64-linux.<host>.users.<username> is a class name or add a note in documentation about it?
also thank you very much for your time ❤

[sini]

@wtf9880 I'll update the documentation soon about the class terminals / built-in reserved keywords.

I'll also give this a long hard think to see if there's anything I can do to lift this restriction, but it has significant design implications and isn't a simple fix -- it involves a re-architecture of the aspect module type system. I was hit by this same issue myself, when I tried to nest aspects under a key 'apps' not realizing that apps is a flake-level reserved type so I would like to resolve it myself.

Don't name your user 'nixos' or 'homeManager' or you'll run into the same issue. ;)

[sini]

@wtf9880 I have a workaround for you in #650 as it would seem it was a different bug than the one i described hitting your specific use-case; so if you must keep your user named user you're unblocked for now; but it'll break when den v2 lands later unless I find an elegant workaround for terminals

I recommend /not/ naming your user user.