Another one, which I bet nobody noticed, is that you can add submodules at the definition site:

{...}: {
  fileSystems."/" = {lib, ...}: {
    options.color = lib.mkOption {
      type = lib.types.str;
      default = "red";
    };
  };
}

{
  fileSystems."/" = {...}: { imports = [ ./root.nix]; };
}

I will note that the former is better than

{ home-manager.users.jdoe = import ./home.nix; }

as the later will lose the file attribute associated with home.nix when reporting error messages.

This is a pretty basic example of what I'd like to be able to do, where the import could also be another profile instead of a nixosModule.

profile1.nix:

imports = [inputs.sops-nix.nixosModules.sops];
sops.secrets.mysecret1={};

profile2.nix:

imports = [inputs.sops-nix.nixosModules.sops];
sops.secrets.mysecret2 = {}

In reply to @infinidoge:inx.moe
Probably the easiest way to accomplish something like this would be to have all of the profiles imported, but control what gets applied with options

Something like:
common:

options = {
  profile1 = lib.mkOption {
    type = lib.types.bool;
    default = false;
  };
  profile2 = lib.mkOption {
    type = lib.types.bool;
    default = false;
  };
  profile3 = lib.mkOption {
    type = lib.types.bool;
    default = false;
  };
};
config = {
  # Common config here
};

profile1:

config = lib.mkIf config.profile1 {
  # Profile 1 config here
};

profile2:

config = lib.mkIf config.profile2 {
  # Profile 2 config here
};

And so on

This is similar to something else I was considering separately, but I was also trying to make each profile fully standalone, so I could safely import and enable them without conflicts.

Can a config block contain imports? One of my issues is that I want my profiles to import their own dependencies, but also not conflict when two profiles share a dependent profile or nixosModule

I want to do something like this programmatically, where all my profiles get collected and wrapped inside a config block, and have a mkEnableOption controlling whether they get enabled.

Can a config block contain imports?
No, because imports are resolved in order to know what config definitions are contributing to the final configuration.

Can a config block contain imports?

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

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

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

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?