If lib.evalModules recursively enumerates the entire tree of imports prior to config eval, and each path in imports is uniquely identifable, why does it opt to throw an error instead of filtering the paths of the merged imports list with something like lib.unique?

Is there some behavior of the module system that depends on being able to apply the same import multiple times while building the options attrset?

In reply to@lehmanator:tchncs.de
I want to have several profile configs that all import the same base profile config or nixosModules, but I'd like to be able to import multiple of them simultaneously, which results in an error. My goal is to have each profile work as a fully standalone unit, but also be granularly composable into more featured profiles. Is there some pattern that would allow this organization scheme?

`profile1`:
```nix
config = lib.mkIf config.profile1 {
  # Profile 1 config here
};
```
`profile2`:
```nix
config = lib.mkIf config.profile2 {
  # Profile 2 config here
};

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

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

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

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

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

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

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
};

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

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

@nbp:mozilla.org Aren't you thinking of _module?

I'm the one who removed that in submodules ;)

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

nix-repl> (nixosConfigurations.ouessant.extendModules { modules = [ ({...}: { fileSystems."/" = {lib, ...}: { options.color = lib.mkOption { type = lib.types.str; default = "red"; }; }; }) ]; }).config.fileSystems."/".color
"red"

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") { … };