1. The NixOS configuration [specifies] which vars backend to use;
 1. The vars definitions are [exported] to [JSON];

This might be somewhat expensive, as you're loading a whole NixOS configuration just to access the vars definitions

Thank you for your followup Robert Hensing (roberth)!

User input isn't part of the design yet, but could be added. I can also imagine that these prompts would be completed with NixOps4 resource data instead of actual interactive user input.

I think prompts could actually be completed with both/either NixOps4 resources data and/or user input.

Maybe I'm a bit off here. I'd have to play around with the PR a bit to get a feel for it. Maybe there's something I'm missing.

@lassulus:lassul.us, made a separate repo, it's a good playground, and we gotta fix the test…

For now my focus is on making stateful, Terraform-style resources work (i.e. making it remember what previous outputs were so that it can actually let resource providers talk to APIs in a sensible way). So Terraform is a pretty good analog for now, in terms of what it will be able to do - just imagine it's Nix instead of HCL so it's easier to transfer info into a NixOS configuration, and unlike in Terranix, you can also refer to real resource values in the Nix language.

While I haven't used Terraform extensively, I feel like I have a good grasp over it. I think the CRUD operations on some secrets storage backend already maps well to the Nixops4 model. The secret generation with the prompts, their outputs going into the script that generate the secrets, seems to be the tricky part, is that why you mentioned focus?

1. The NixOS configuration [specifies] which vars backend to use;
2. The vars definitions are [exported] to [JSON];

This might be somewhat expensive, as you're loading a whole NixOS configuration just to access the vars definitions. (broad adoption of modular services could drive down that evaluation cost, 2-4× for system.build.toplevel, maybe more for evaluating a small part of a config?)

It is a little expensive, I know the clan team has been trying to bring the cost down, and do some caching. I am not sure I understand how modular services would reduce evaluation time? Would it help avoid loading the entire NixOS module library, which I currently understand is one of the main issues regarding NixOS configurations eval times (and RAM usage)?

But to really see the potential:

1. Make significant cuts in modules-list.nix and fix a few broken options references
2. Watch instantiation of toplevel go down from 4.0 to 1.4 seconds.

• https://github.com/NixOS/nixpkgs/issues/137168

Seems safe to assume the list hasn't shrunk in the past 3.5 years :)