In reply to @nbp:mozilla.org
Sam Lehman: Yes, evalModules should capture the whole tree of imports and deduplicated moduled key property.
However, if you are using flakes, and define a nixosModules within the flake.nix file, then the key attribute is not initialized to any value which can safely be deduplicated.

Not sure I follow.

Is key an intermediate attr of the loaded modules that doesn't make it into the resulting config? The default behavior breaks when I try to do what I described.

I'm also using https://github.com/divnix/std and I'd like to reference other profiles using cell.nixosModules.<name> before they reach my flake outputs.

In reply to @nbp:mozilla.org

Can a config block contain imports?

No, because imports are resolved in order to know what config definitions are contributing to the final configuration.

In reply to @nbp:mozilla.org

You can create an option, which value is used as part of:

  config = mkIf (config.profile == "profile_42") { … };

I don't think this structure will work for how I'm trying to set my profiles up.

I might be able to create options.profiles and wrap each profile in their own module machinery, so the entire profile gets added to config and creates options.profiles.<name>.enable which controls activation of the profile. My only issue is handling imports.

nixosModule.profile_option = {lib, ...}: {
  key = "profile_option";
  options.profile = lib.mkOption { ... };
};

In reply to @nbp:mozilla.org
I would say that an upstream issue, others would have the same problem as you, so you might as well fix it upstream.

Definitely something I'd expect others to have problems with, so I'd be down to contribute to a fix.

How would I go about debugging lib.evalModules?