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.)
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?