Why does this usage of builtins.getFlake recurse infinitely?

lib.modules.evalModules {
  modules = [
    ({ agenix ? builtins.getFlake "github:ryantm/agenix", ... }: {
      imports = [agenix.darwinModules.age];
    })
  ];
}

I’ve got a similar expression that looks like this, which DOESN’T recurse:

lib.modules.evalModules {
  modules = [
    (args @ {lib, pkgs, ...}: let
  # prefer flake inputs version of agenix, unless the arg is missing
  # fall back to main of the repo otherwise
  commit = "main";
  pinned = builtins.fetchTarball {
    url = "https://github.com/ryantm/agenix/archive/${commit}.tar.gz";
    sha256 = "006ngydiykjgqs85cl19h9klq8kaqm5zs0ng51dnwy7nzgqxzsdr";
  };
  repo = lib.attrsets.attrByPath ["inputs" "agenix"] pinned args;
in {
  imports = ["${repo}/modules/age.nix"];

  environment.systemPackages = [
    (pkgs.callPackage "${repo}/pkgs/agenix.nix" {})
  ];
})
  ];
}

You’ll notice that the way I access attributes of the repo is a little different.

I’ve been interested in solving the problem of unifying flake and non-flake interfaces to system configurations through the unification of the API contracts between modules. So I’ve been playing with expressions of this form because I want to see if I can figure out how to have impure evaluations ‘replay’ the effects of specialArgs into modules.

Any insights? My current thought is that forcing ‘repo’ results in a static expression which lets the imports resolve.

Nothing about these expressions is similar. In any case, what command are you running and what is the error?

(I suspect things are infrec-ing because agenix is not a module arg, since providing the formal arg will cause nix to try to eval it, and the arg’s default doesn’t help you here, due to how evalModules handles formals.)

1 Like

Just trying these expressions out in the repl, not even running any commands per se.

My hunch also is similar: arg defaults don’t really work with the modules system here

I found this which seems very relevant to my usecase. I’m basically trying to do the same thing with the ‘sources’ module argument:

Well that PR has already been merged, so you can just use it directly.
Though there is no sources module arg.

1 Like

You’re right. I’m basically trying to encapsulate npins style inputs via a custom module argument, and then shim in flake stuff into the same interface. Just trying to refactor my configuration to improve the modularity of each module in my ecosystem.

Since that PR (which I just found) only recently hit master, sounds like it’ll be a waiting game?

It’s already reached unstable by now.
https://nixpkgs-tracker.ocfox.me/?pr=442886

That’s in fact the case.
Since it’s at least strict in the attrnames, it infrecs when config._module.args.agenix isn’t provided.

1 Like

Thank you for the assist, was beating my head against this for a few hours :grinning: