Regression in PR #353 causes evaluation error (missing _module.args)

[cmetz]

Since the merge of PR #353, my configuration (non-flake / like vic/vix) fails during evaluation with the following error trace:

 … while evaluating definitions from `/home/loom/dotfiles/modules/den.nix, via option den.ful.gloom.apps.provides.helix.homeManager':
┃ 
┃        … while evaluating the module argument `inputs'' in ":anon-4:anon-1:anon-1:anon-2:anon-2:anon-2:anon-1:anon-2:anon-1:anon-1:anon-1:anon-1:anon-1:anon-1:anon-1:anon-1:anon-1":
┃ 
┃        … noting that argument `inputs'` is not externally provided, so querying `_module.args` instead, requiring `config`

The issue seems related to how namespaces are handled. My current namespace configuration looks like this:

{
  inputs,
  den,
  ...
}:
{
  imports = [
    inputs.den.flakeModule
    (inputs.den.namespace "gloom" true)
  ];

  _module.args.__findFile = den.lib.__findFile;
}

Helix aspect definition:

{ __findFile, ... }:
{
  gloom.everywhere.includes = [ <gloom/apps/helix> ];

  gloom.apps.provides.helix.homeManager =
    {
      inputs',
      config,
      pkgs,
      lib,
      ...
    }:
    {
      home.shellAliases = {
        e = "hx";
      };
...

For context: inputs' and self' are normally provided via den.default.includes as shown below:

    den.default.includes = [
      den.provides.define-user
      den.provides.inputs'
      den.provides.self'
    ];

It appears that the evaluation of inputs' now triggers a circular dependency or fails to resolve correctly through _module.args in this specific setup.

[vic]

Hey, @cmetz thanks for reporting I will take a look. Looks like we need more tests.

[cmetz]

Hey, @vic thanks, i'll like to provide some tests, but I'm still struggle when handling more complex nix code.

[Adda0]

Indeed, it seems to be a failure with namespaces. I am getting the same with aspects inside my namespace.

[vic]

Yep, I'm on it right now @Adda0 ;)

[vic]

my brain is not working at all right now. I wanted to fix this today but I wont be able. Also I will be away for Sabbath, so I will continue on sunday, hopefully with a renewed brain that can actually think.

easiest fix would be to restore namespace.nix where we had some attribute filtering, but I dont want to do that, I intentionally removed that becasue I believe that was a hack from mine. I will try later on sunday.

[cmetz]

I think non namespace aspects like den.aspects.myaspect.homeManager = {inputs', self', ...}: ... are also broken.

[vic]

see the test at #377 can you provider other failing test ? I added that one based on namespaces, but if we can reduce it to expose the bug without namespaces that'd be better.

[cmetz]

@vic i'll do that. but maybe the pr introduced multiple issues, so we should test against multiple scenarios in your pr might be a small bug. I' think it should be homeManger.home.packages instead of homeManger.packages.

[vic]

I' think it should be homeManger.home.packages instead of homeManger.packages.

good catch, as I said at times my brain just don't work. I've fixed that, also added a couple of tests.

looks like if add adaptArgs = lib.id to home-env.nix like this tests work, but sadly the unfree battery breaks. I still need to understand how the regression happened at #353 since that PR is mainly about namespaces, maybe the change at parametric.

[cmetz]

Having started with your framework only last week, I find it quite complex to navigate. However, I consulted Gemini, and it provided the following explanation, which might be helpful in identifying the issue:

Root Cause Analysis:
The recent changes introduced to fix function argument reflection (PR #352) unintentionally broke dependency injection for custom contextual providers (like inputs'). The issue stems from replacing the functorType wrapper with lastFunctionTo.

Specifically, two major things changed under the hood:

Loss of implicit callerArgs evaluation: Previously, the __functor wrapper in types.nix automatically intercepted and passed contextual arguments (e.g., { host }, { home }, { user }) down to the nested aspect functions. By switching to lastFunctionTo, the framework now returns the raw, unapplied function to preserve lib.functionArgs compatibility. As a result, the contextual functions are no longer automatically evaluated.

Removal of deep functor evaluation: The PR removed the functorModules resolution logic from namespace.nix and bypassed deep evaluation in parametric.nix.

Impact:
Because the framework no longer actively evaluates these nested contexts, custom providers that rely on dynamic aspects (e.g., combining osAspect, userAspect, and hmAspect into a single provider) are now passed to the Nix module system as raw, unresolved functions. The module system doesn't know how to handle these missing arguments, causing the provider injection to fail silently or throw errors.

Migration Path / Workaround:
To fix custom providers under the new architecture, we must stop relying on the framework's implicit argument injection. The solution is to migrate from "Framework-driven Context Injection" to "Standard Nix Module Conditionals".

Instead of passing an array of unapplied, context-specific functions to the provider, they should be combined into a single, unified Nix module. By making the context variables (host, user, home) optional module arguments and wrapping the respective logic in standard lib.mkIf statements, the module can natively adapt itself to the current evaluation environment without requiring deep functor resolution from the framework.

he suggests something like this and it seemed to work, but maybe adaptargs is better.

{
  den,
  lib,
  withSystem,
  ...
}:
let
  inherit (den.lib) parametric;

  description = ''
    Provides the `flake-parts` `inputs'` (the flake's `inputs` with system pre-selected)
    as a top-level module argument.

    This allows modules to access per-system flake outputs without needing
    `pkgs.stdenv.hostPlatform.system`.

    ## Usage

    **Global (Recommended):**
    Apply to all hosts, users, and homes.

        den.default.includes = [ den._.inputs' ];

    **Specific:**
    Apply only to a specific host, user, or home aspect.

        den.aspects.my-laptop.includes = [ den._.inputs' ];
        den.aspects.alice.includes = [ den._.inputs' ];

    **Note:** This aspect is contextual. When included in a `host` aspect, it
    configures `inputs'` for the host's OS. When included in a `user` or `home`
    aspect, it configures `inputs'` for the corresponding Home Manager configuration.
  '';

  mkAspect =
    class: system:
    withSystem system (
      { inputs', ... }:
      {
        ${class}._module.args.inputs' = inputs';
      }
    );

  inputsModule =
    {
      host ? null,
      user ? null,
      home ? null,
      ...
    }:
    lib.mkMerge [
      (lib.mkIf (host != null && user == null) (mkAspect host.class host.system))

      (lib.mkIf (user != null && host != null) (
        lib.mkMerge (map (c: mkAspect c host.system) user.classes)
      ))

      (lib.mkIf (home != null) (mkAspect home.class home.system))
    ];
in
{
  den.provides.inputs' = parametric.exactly {
    inherit description;
    includes = [ inputsModule ];
  };
}

[vic]

@cmetz I know you wanted to help, but trust me when I say that I find it hard to take seriously anything generated by AI, take a look at the fix: https://github.com/vic/den/pull/377/changes#diff-b0482e343dfd953e913120a9576f9e2e34b2281e7758cafafd500d93b6c29832L51 it was not about using more mkMerge but less of it. Many agents Claude and Gemini I've seen that don't quite get it, and many times suggest reverting to "normal" traditional Nix idioms they were trained with.

For other people (not personally @cmetz), please don't expect that I will take the time to read AI generated slop, because most of they time they are just wrong about the right solution. I accept AI asisted contributions, as long as people show evidence of they having better knowledge of Den than just what the AI generates for them.

Having said that, even bug reports are good contributions to Den, thanks @cmetz, I hope this #377 fixes the issue.