error: attribute 'user' missing

[michaelBelsanti]

I'm having trouble using the user context in the way demonstrated by the autologin module in the user template.

This is a simplified version of what I'm doing:

{ den, ... }
{
  den.hosts.x86_64-linux.hades.users.quasi = { };
  den.aspects.quasi.includes = [ den.aspects.nushell ];
  den.aspects.nushell =
    { user, ... }:
    {
      nixos =
        { pkgs, ... }:
        {
          environment.systemPackages = [ pkgs.nushell ];
          users.users.${user.userName}.shell = pkgs.bashInteractive;
        };
      homeManager = {
        programs.bash.initExtra = ''
          # https://discourse.nixos.org/t/nushell-as-default-shell/68609/17
          # Some programs launch interactive shells and pretend
          # to use them; such programs always expect a form of POSIX
          # shell.
          #
          # If you don't use programs like that, you can just skip
          # this conditional.
          if ! [ "$TERM" = "dumb" ]; then
            exec nu
          fi
        '';
      };
  };
}

Building hades I end up with this:

error:
       … while calling the 'head' builtin
         at /nix/store/3fis83br4c3xkqh3457ji3w37gihzk6s-source/lib/attrsets.nix:1696:13:
         1695|           if length values == 1 || pred here (elemAt values 1) (head values) then
         1696|             head values
             |             ^
         1697|           else

       … while evaluating the attribute 'value'
         at /nix/store/3fis83br4c3xkqh3457ji3w37gihzk6s-source/lib/modules.nix:1118:7:
         1117|     // {
         1118|       value = addErrorContext "while evaluating the option `${showOption loc}':" value;
             |       ^
         1119|       inherit (res.defsFinal') highestPrio;

       (stack trace truncated; use '--show-trace' to show the full trace)

       error: attribute 'user' missing
       at /nix/store/55z53i8nflvx4y9662rc0b6xb9y43b66-source/lib/modules.nix:685:33:
          684|             "noting that argument `${name}` is not externally provided, so querying `_module.args` instead, requiring `config`"
          685|             config._module.args.${name}
             |                                 ^
          686|           )

I'm sure I'm messing something up with the dependency system, but to me, it looks pretty much the same as the autologin example in the template.

[vic]

Hey @michaelBelsanti, so glad to have you around here,and personally, quite happy that you are testing den.

You are absolutely right!(tm)

Your usage-intuition is correct, I have created an issue #92 to fix this, because I believe it is exactly what many people will try at first.

I will provide a couple of workarounds, until the PR #93 fixing this lands.

For now, if you are in a hurry, use one of the following approaches to define nushell:

• A) Define nushell inside any .provides. tree

den.aspects.utils.provides.nushell = { user, ... }: { };
den.aspects.quasi.includes = [ den.aspects.utils._.nushell ];

This is basically why the eg.autologin example you mention does work.

A function definition on eg namespace like, eg.autologin = { user, ...}: {} is inside a .provides sub-tree, just like if you were doing den.aspects.utils.provides. A a namespace like eg is just a convenience shorthand into a .provides sub-tree.

The PR fixing this, basically changes our den.aspects to be just like if it was a .provides subtree:

options.den.aspects = mkOption {
  type = submodule { freeformType = flake-aspects.types.providerType; };
}

• B) Define nushell's functor.

An alternative is to define the __functor attribute explicitly:

den.aspects.nushell.__functor = aspect: { user, ... }: {
  nixos = ...;
  homeManager = ...;
} 

But none of these will be needed once #93 lands.

[vic]

Hey @michaelBelsanti,

Thanks for including both hosts good and bad so I could spot the difference on what is happening.

Ok, here's what is happening. I'm not sure if this is a bug. but maybe there's something we can do to improve perhaps the documentation to be more explicit about why this is hapenning, or in some way to improve the UX to avoid surprises, I'm still considering what should be done.

From your code, the difference is in how wayland aspect is being included. wayland expects parameters (a context) to produce an aspect.

The thing is, all aspects that are created by Den for Hosts, User and Homes have a __functor = parametric.atLeast, that means, they are functions that forward the context they receive to any function on their .includes that can take that context.

A Parametric aspect is one whose sole purpose is to dispatch to other aspects based on an existing context.

• relevant documentation

This is why good.includes works:

den.aspects.good.includes = [
  den.aspects.good_cosmic 
  den.aspects.wayland
];

Since good is a Host, den has already created the aspect for you:

den.aspects.good.__functor = den.lib.parametric.atLeast

which correctly forwards any context to wayland.
the osDependencies function (from dependencies.nix) is the one that includes the other (static) aspect good_cosmic.

Now the case for the bad Host. den.aspects.bad is also parametric, and it includes bad_cosmic which is not (it is simply a non-functional aspect)

bad_cosmic = {
  nixos = ...;
  includes = [ wayland ];
}

now, given that bad_cosmic itself is not a function, where should wayland take its parameters from ? bad_cosmic knows nothing on how to provide { host , ... } to its includes. like calling a function bad_cosmic() when and it internally calling wayland(host), you need access to host in bad_cosmic first.

So one solution is

# this context is absolutely anyting
# bad_cosmic does not impose any restriction on how the context
# must look like for it to work
bad_cosmic = ctx: {
  # does not change (adapts) the context in any way,
  # just forwards the context to any includes
  __functor = den.lib.parametric ctx;
  includes = [ wayland ];
}

docs on adapting context, example about forwarding context

Another way to solve this is:

bad_cosmic = { 
  __functor = den.lib.parametric.atLeast;
  includes = [ wayland ];
};

In both cases bad_cosmic is a function taking any context, in the first case it is a real-function and in the second it is an acts-like-function attribute. The second, also takes any context and will forward it to their includes when they support it.

Now, there's one catch (and this is the thing I'm not sure about what to document/change).

den.lib.parametric API only cares about functions in includes, its job is to dispatch functions, and nothing else. (as documented)

bad_cosmic = {
  __functor = den.lib.parametric.atLeast;
  includes = [ wayland ];
  nixos.foo = "bar";
};

When called, bad_cosmic { x = 1; } it will forward { x } to wayland, if wayland supports that. But bad_cosmic does NOT care about owned configs like nixos.foo.

To fix this, you would have to do:

bad_cosmic = { aspect, ... }: {
  __functor = den.lib.parametric.atLeast;
  includes = [
    den.aspects.wayland
    # this includes bad_cosmic owned config
    (den.lib.owned aspect) # see dependencies.nix doing it.
  ];
  nixos.services = {
    desktopManager.cosmic.enable = true;
    displayManager.cosmic-greeter.enable = true;
  };
};

Access to { aspect, ...} is not currently documented in Den, but it is a flake-aspects feature. That gives you access to the aspect being defined (it is basically just an alias for config in the aspect-submodule).

from flake-aspects first code example:

_.emulation = { aspect, ... }: {
  nixos = {};
}

[vic]

I will be thinking on how to improve the UX for this. Most likely I will introduce another parametric.<something> combinator, that also takes owned configs into account. Or, make parametric.atLeast and friends DO take owned configs, and introduce another parametric.forwardAtLeast and friends that do not.

[vic]

As a side-note, almost all my previous examples using functors look like:

bad_cosmic = { aspect, ... }:
{
  __functor = parametric.atLeast;
  includes = [ wayland (owned aspect) ];
  nixos.foo = "bar";
}

but the following is exactly the same:

bad_cosmic = { aspect, ...}: parametric.atLeast {
  includes = [ wayland (owned aspect) ];
  nixos.foo = "bar";
}

[vic]

@michaelBelsanti I've merged #98

From now, this is the recommended way to create parametric aspects (still have to update docs):

# This aspect can take any type of context
bad_cosmic = parametric {
  nixos.foo = "bar";
  includes = [ wayland ];
};

and it should correctly forward context and include owned modules. See test here

EDIT: added more tests showcasing other parametric functors.

[michaelBelsanti]

now, given that bad_cosmic itself is not a function, where should wayland take its parameters from ? bad_cosmic knows nothing on how to provide { host , ... } to its includes. like calling a function bad_cosmic() when and it internally calling wayland(host), you need access to host in bad_cosmic first.

Nice, thats pretty much what I had assumed was happening. I didnt realize host aspects had __functor set by default, so I was confused about why it worked there and not in other aspects.

Appreciate all of the help! Definitely need to spend more time playing around with parametric aspects. I'll take a look at those tests to familiarize myself with the rest.