there are several representations that get produced along the way:

• your colmena hive (the original representation, what you would put in hive.nix with meta and your hosts as attributes)
• somewhere in between there is also a nixos module system to eval just the meta section (let it have defaults, etc.)
• nodes attrset (which is very similar to nixosConfigurations) + some specific meta attributes
• the colmenaEval attrset, which is what the colmena cli needs to do its job

now all these transitions between the representation are currently quite entangled into one big nix function that goes all the way from your colmena hive to colmenaEval

what has improved lately is, that you can decide to call this makeHive function yourself and provide colmena a pre-processed colmenaEval attrset

this also makes it possible to write other functions that produce the same format, but from a different source format

and now we can write other useful functions to transform between these representations:

• pre-existing nixosConfigurations + nixos module system for metaOptions -> colmenaEval ; with this we can use the colmena cli together with a pre-existing nixosConfigurations definition. use colmena cli without the hive concept, or with a different hive mechanism
• colmena hive -> nixosConfigurations ; use colmena hives with nixos-rebuild, very simple to implement with makeHive

and so on

there are several representations that get produced along the way:

• your colmena hive (the original representation, what you would put in hive.nix with meta, defaults and your hosts as attributes)
• somewhere in between there is also a nixos module system to eval just the meta section (give it type checking, default values, etc.)
• nodes attrset (which is very similar to nixosConfigurations) + some specific meta attributes
• the colmenaEval attrset, which is what the colmena cli needs to do its job

now all these transitions between the representation are currently quite entangled into one big nix function that goes all the way from your colmena hive to colmenaEval

what has improved lately is, that you can decide to call this makeHive function yourself and provide colmena a pre-processed colmenaEval attrset

this also makes it possible to write other functions that produce the same format, but from a different source format

I also generate a groups module arg:

  _module.args.groups = let
    tagNames = lib.unique (
      lib.concatLists (
        lib.mapAttrsToList (
          name: host: host.config.deployment.tags
        ) args.nodes
      )
    );
  in lib.genAttrs tagNames (
    tagName: lib.filter (
      host: lib.elem tagName host.config.deployment.tags
    ) (
      lib.attrValues args.nodes
    )
  );

I also generate a groups module arg:

{ ... }@attrs:

{
  _module.args.groups = let
    tagNames = lib.unique (
      lib.concatLists (
        lib.mapAttrsToList (
          name: host: host.config.deployment.tags
        ) args.nodes
      )
    );
  in lib.genAttrs tagNames (
    tagName: lib.filter (
      host: lib.elem tagName host.config.deployment.tags
    ) (
      lib.attrValues args.nodes
    )
  );
}

I also generate a groups module arg:

{ lib, ... }@attrs:

{
  _module.args.groups = let
    tagNames = lib.unique (
      lib.concatLists (
        lib.mapAttrsToList (
          name: host: host.config.deployment.tags
        ) args.nodes
      )
    );
  in lib.genAttrs tagNames (
    tagName: lib.filter (
      host: lib.elem tagName host.config.deployment.tags
    ) (
      lib.attrValues args.nodes
    )
  );
}

I also generate a groups module arg:

{ lib, ... }@args:

{
  _module.args.groups = let
    tagNames = lib.unique (
      lib.concatLists (
        lib.mapAttrsToList (
          name: host: host.config.deployment.tags
        ) args.nodes
      )
    );
  in lib.genAttrs tagNames (
    tagName: lib.filter (
      host: lib.elem tagName host.config.deployment.tags
    ) (
      lib.attrValues args.nodes
    )
  );
}