Calling `mkFlake` iteratively

[Alxandr]

Hello, I'm trying to refactor my flake into was is effectively subflakes (though with shared lock/inputs). I'm basically just trying not to have to deal wth multiple git repositories if I can avoid it, due to the added maintainance overhead that brings. I planned to effectively make these "stages" such that I have 00-base, and 01-nixos. My plan was to do something like this (pseudocode):

let
  base = mkFlake { inherit inputs; } (import ./01-base);
  nixos = mkFlake { inputs = inputs // { inherit base; }; } (import ./02-nixos);
in
  mkFlake { inputs = inputs // { inherit base nixos; }; } (import ./config)

However, this very quickly leads to infinite recursion. Another thing that's stumped me, is that while I can do { home-manager, ... }: {} as a module in all 3 mkFlake invocations, I can't do { base, ... }: {}.

I've gone through the issues here that deal with dogfooding, and while that's pretty similar, I would really like to be able to produce multiple stages to make the dependencies much more explicit (and hopefully enforced). I'm however unable to get something like this to work, so I need some guidance.

[roberth]

Somewhat off topic, but relevant is to avoid import

 (import ./01-base)

It's better to do just pass ./01-base, because import drops the file name. Errors will be a little better when you don't call import. If you need to pass extra arguments, call flake-parts-lib.importApply file args instead; that also preserves the file name.

As for the real problem, I don't really see it.
I probably wouldn't bother with the staged approach, but I don't see a fundamental problem with it.
Kind of hard to see what's wrong without the code, but maybe the error trace reveals something. The module system tends to add some relevant context via custom trace entries. (And Nix 2.24 shows those unconditionally.)
If you also pass --show-trace it gets a lot more verbose, but occassionally that's necessary.

[Alxandr]

Sorry, my head is still not able to fully wrap around the concept of fixed points and calling functions with their own output. I think the issue I had was that all invocations to mkFlake were using the same outputs, but I think I've managed to create something that solves that. I've created a pretty small poc and would be really appreciative of a sanity-check: https://github.com/Alxandr/nix-flake-poc.

If this is a reasonable approach, maybe it makes sense to add something similar to flake-parts?