pkgs not passed when using config in parametric aspect

[Diax170]

I'm currently converting my flake-parts config to den. Now I'm trying to pass a common function as per #32:

{ lib, ... }: {
  options.mylib = lib.mkOption { type = lib.types.anything; };

  config.mylib = rec {
    ensureList = x: if (builtins.isList x) then x else [ x ];

    # Creates a parametric Home Manager (user) Den aspect that installs packages
    # packages: a package or list of packages to be installed. Automatically replaces string elements with `pkgs.${element}`
    # guiPackages: same as `packages` but only installed if `host.my.gui` is set
    mkPkgAspect = packages: guiPackages: {
      homeManager = { host, pkgs, ... }: {
        home.packages = map (x: if (builtins.isString x) then pkgs.${x} else x) (
          ensureList packages ++ lib.optionals host.my.gui (ensureList guiPackages)
        );
      };
    };
  };
}

here is an example aspect I use it in:

{ config, ... }: {
  den.aspects.user.programs.groups.androidTools = config.mylib.mkPkgAspect "android-tools" "scrcpy";
}

now apparently if I use config, pkgs don't get passed:

error: function 'homeManager' called without required argument 'pkgs'
       at /home/oli/nix-dots/modules/lib.nix:24:21:
           23|     mkPkgAspect = packages: guiPackages: {
           24|       homeManager = { host, pkgs, ... }: {
             |                     ^
           25|         home.packages = map (x: if (builtins.isString x) then pkgs.${x} else x) (

when I define the function within a single file, everything works fine:

let
  ensureList = x: if (builtins.isList x) then x else [ x ];

  mkPkgAspect = packages: guiPackages: {
    homeManager = { host, pkgs, lib, ... }: {
      home.packages = map (x: if (builtins.isString x) then pkgs.${x} else x) (
        ensureList packages ++ lib.optionals host.my.gui (ensureList guiPackages)
      );
    };
  };
in
{
  den.aspects.user.programs.groups.androidTools = mkPkgAspect "android-tools" "scrcpy";
}

[MLuc24]

The config part is a red herring — the same signature written inline fails identically. What breaks it is asking for host and pkgs in the same function, because that makes Den classify it as the wrong kind of function.

Den decides whether a function is a module or a scope function with this, in nix/lib/aspects/types.nix:

isSubmoduleFn = canTake.upTo {
  lib = true;
  config = true;
  options = true;
};

and the comment directly under it states the two paths:

Functions with named args (like { host, ... }: { nixos = ...; }) are coerced to { includes = [fn]; } so the fx pipeline resolves them via bind.fn effects. NixOS module functions (taking lib/config/options) are NOT coerced — they're handled by wrapChild's normalizeModuleFn.

canTake resolves like this (nix/lib/can-take.nix):

args = lib.functionArgs func;
required = builtins.filter (n: !args.${n}) (builtins.attrNames args);
satisfied = valid && builtins.all (n: params ? ${n}) required;
...
upTo = satisfied && intersect != { };

So a function counts as a module only if every required argument is one of lib, config, options, and it names at least one of them. Your { host, pkgs, ... } requires host and pkgs, neither of which qualifies, so satisfied is false, Den treats it as a scope function, and calls it with the scope context — which carries host, user, home, OS and friends, but never pkgs. Hence the error naming pkgs and not host.

Two consequences worth knowing before you rewrite it. { pkgs, ... } alone fails the same test, so you cannot get pkgs by simply dropping host. And a bare { ... }: fails too — required is empty so satisfied holds, but intersect is {} and upTo needs it non-empty.

The way out is to stop mixing the two arg sets and nest them instead: an outer scope function for host, an inner module function for pkgs, with the module function naming an allowed argument and capturing the rest:

mkPkgAspect = packages: guiPackages:
  { host, ... }: {
    homeManager =
      { lib, ... }@args:
      {
        home.packages = map (x: if (builtins.isString x) then args.pkgs.${x} else x) (
          ensureList packages ++ lib.optionals host.my.gui (ensureList guiPackages)
        );
      };
  };

The outer function requires only host, so it goes through the scope pipeline and gets it. The inner one requires only lib, which satisfies canTake.upTo, so it is handed to the module system as a real Home Manager module — and args.pkgs is then the module system's pkgs, which is what you wanted all along.

Your call site does not need to change; config.mylib.mkPkgAspect "android-tools" "scrcpy" now yields a scope function rather than an attrset, and Den resolves that the same way it resolves any { host, ... }: aspect.

[Diax170]

Hello, thanks for support, but I'm sorry to tell you that this fails too:

┃        error: attribute 'pkgs' missing
┃        at /home/oli/nix-dots/modules/lib.nix:27:65:
┃            26|         {
┃            27|           home.packages = map (x: if (builtins.isString x) then args.pkgs.${x} else x) (
┃              |                                                                 ^
┃            28|             ensureList packages ++ lib.optionals host.my.gui (ensureList guiPackages)
┣━━━                                                            

I figured out I'll be using this workaround for now:

lib.nix:

{ lib, ... }: {
  options.libPath = lib.mkOption { type = lib.types.path; };
  config.libPath = ./_lib.nix;
}

_lib.nix:

{
  lib ? { },
}:
rec {
  ensureList = x: if (builtins.isList x) then x else [ x ];

  mkPkgAspect = packages: guiPackages: {
    homeManager = { host, lib, pkgs, ... }: {
      home.packages = map (x: if (builtins.isString x) then pkgs.${x} else x) (
        ensureList packages ++ lib.optionals host.my.gui (ensureList guiPackages)
      );
    };
  };
}

android-tools.nix:

{ config, ... }: {
  den.aspects.user.programs.groups.androidTools = (import config.libPath { }).mkPkgAspect "android-tools" "scrcpy";
}

This way all of the arguments are passed properly and there's no import hell since the lib path is stored in config

[MLuc24]

My answer was wrong, and the fix I gave you was wrong for the same reason — sorry for the wasted round.

Mixing context args and module args in one function is not a mistake at all; it is a documented feature. From the Class Modules page:

As a convenience, you can also write class modules in flat form, mixing context args and module-system args in a single function:

{
  nixos = { host, config, pkgs, ... }: {
    networking.hostName = host.name;
  };
}

The pipeline inspects builtins.functionArgs, identifies which args exist in the current context, pre-applies those values, and advertises only the remaining args to the module system via lib.setFunctionArgs.

So { host, pkgs, ... } is the intended shape, host should be pre-applied from context and pkgs left to the module system. My isSubmoduleFn story described a different code path and does not explain your error. Drop the @args indirection I suggested and name pkgs in the signature again.

Two details from the same page that my version got wrong, in case either matters to you:

Flat-form class modules must include ... in their argument pattern.

Note that for aspect-level context functions (the outer wrapper), ... is not needed and should be omitted -- these receive only the context args they declare.

I wrote { host, ... }: for the outer wrapper, which is backwards from that convention.

The page also gives the diagnostic for a class module that does not behave, and it is worth checking before anything else:

When a class module requires an entity arg that isn't in the current context (e.g., { user, config, ... } at a host scope where no user exists), the module is skipped. ... Only missing entity args (the schema kinds — host, user, home, …) trigger this skip; ordinary module-system args with no default are left for the module system to resolve.

If your class module isn't taking effect, check whether all its entity args are in context at the scope where it's being resolved.

Note that homeManager resolves at user scope, and the documentation's own example pairs it with user rather than host:

homeManager = { user, config, ... }: {
  home.username = user.userName;
};

Whether host is in context there is the thing I would confirm first, since host.my.gui is what you need it for.

Beyond that I would not guess again. The cheap experiment that would actually localise this: write the same aspect out literally, without going through config.mylib, using { host, pkgs, ... } and no outer wrapper. The documentation says that must work. If it does work literally and only fails through config.mylib, then the config route is the variable rather than the argument pattern — and that is a much sharper report for the maintainers than anything I can infer from reading the pipeline.