I'm currently doing a hack like

    nixosConfigurations = lib.mapAttrs (name: config: let
      nodeNixpkgs = self.outputs.colmena.meta.nodeNixpkgs.${name} or self.outputs.colmena.meta.nixpkgs;
      nodeNixos = import (nodeNixpkgs.path + "/nixos/lib/eval-config.nix");
      in nodeNixos {
        modules = [
          self.outputs.colmena.defaults
          config
          inputs.colmena.nixosModules.deploymentOptions
          {
            _module.args.name = name;
            _module.args.nodes = self.outputs.nixosConfigurations;
            nixpkgs.overlays = [ nodeNixpkgs.lib.flakeOverlay (import ./overlay.nix) ];
          }
        ];
        inherit (nodeNixpkgs) system;
      }
    ) (builtins.removeAttrs self.outputs.colmena ["meta" "defaults"]);

to be able to get at least an approximation of the configs (enough to be able to build it in hydra, for example)

And the colmena package itself could be re-exported to my flake.
So that I do nix run .#colmena apply and it uses the colmena version pinned in my flake.

So you mean something like:

mkFlake ...

->

nixosConfigurations = ...
__colmena = ...

To further expand on that, consuming the existing nixosConfigurations is problematic, since Colmena needs to insert two things into the configuration: Modules (deployment.* options and configs) as well as module arguments (name and nodes which allows you to refer to configurations of other nodes in the cluster). This is in part following the design decisions of NixOps and morph. Inserting them cannot be cleanly done in case of nixosConfigurations which contains complete, evaluated configurations rather than individual NixOS modules.

We could remove this need and make the user specify the deployment.* configs externally, outside the NixOS configuration. This is the approach that deploy-rs takes (the deploy output). The downside is two-fold:

1. The level of configuration composition possible will be limited. As an example, I set deployment.tags = [ "routers" ]; in my router module so enabling it will automatically make colmena apply --on @routers deploy to this node. Additionally, I use the added nodes argument extensively in my configuration to set up a WireGuard mesh and iBGP peerings between my nodes.
2. The effect Colmena can have on the target node configuration will be limited. For instance, Colmena creates the ${name}-key.service for each secret file defined in deployment.keys, which will no longer be possible. deploy-rs uses a deploy binary copied alongside the profile to implement activation and other features.

The end result is a level of functionality noticeably different from "normal" Colmena that would necessitate a lot of documentation changes and still be confusing to users.

My interpretation is

hive = { defaults = ...; meta = ...; nodeA = ...; };
nixosConfigurations = (colmena.evalHive self.outputs.hive).nixosConfigurations;

In reply to @zhaofeng:zhaofeng.li

To further expand on that, consuming the existing nixosConfigurations is problematic, since Colmena needs to insert two things into the configuration: Modules (deployment.* options and configs) as well as module arguments (name and nodes which allows you to refer to configurations of other nodes in the cluster). This is in part following the design decisions of NixOps and morph. Inserting them cannot be cleanly done in case of nixosConfigurations which contains complete, evaluated configurations rather than individual NixOS modules.

We could remove this need and make the user specify the deployment.* configs externally, outside the NixOS configuration. This is the approach that deploy-rs takes (the deploy output). The downside is two-fold:

1. The level of configuration composition possible will be limited. As an example, I set deployment.tags = [ "routers" ]; in my router module so enabling it will automatically make colmena apply --on @routers deploy to this node. Additionally, I use the added nodes argument extensively in my configuration to set up a WireGuard mesh and iBGP peerings between my nodes.
2. The effect Colmena can have on the target node configuration will be limited. For instance, Colmena creates the ${name}-key.service for each secret file defined in deployment.keys, which will no longer be possible. deploy-rs uses a deploy binary copied alongside the profile to implement activation and other features.

The end result is a level of functionality noticeably different from "normal" Colmena that would necessitate a lot of documentation changes and still be confusing to users.

In reply to @zhaofeng:zhaofeng.li

To further expand on that, consuming the existing nixosConfigurations is problematic, since Colmena needs to insert two things into the configuration: Modules (deployment.* options and configs) as well as module arguments (name and nodes which allows you to refer to configurations of other nodes in the cluster). This is in part following the design decisions of NixOps and morph. Inserting them cannot be cleanly done in case of nixosConfigurations which contains complete, evaluated configurations rather than individual NixOS modules.

We could remove this need and make the user specify the deployment.* configs externally, outside the NixOS configuration. This is the approach that deploy-rs takes (the deploy output). The downside is two-fold:

1. The level of configuration composition possible will be limited. As an example, I set deployment.tags = [ "routers" ]; in my router module so enabling it will automatically make colmena apply --on @routers deploy to this node. Additionally, I use the added nodes argument extensively in my configuration to set up a WireGuard mesh and iBGP peerings between my nodes.
2. The effect Colmena can have on the target node configuration will be limited. For instance, Colmena creates the ${name}-key.service for each secret file defined in deployment.keys, which will no longer be possible. deploy-rs uses a deploy binary copied alongside the profile to implement activation and other features.

The end result is a level of functionality noticeably different from "normal" Colmena that would necessitate a lot of documentation changes and still be confusing to users.

1. The nodes argument doesn't require colmena though. nixosConfigurations can reference self.outputs.nixosConfigurations to get at other hosts.
2. (covers deployment.tags as well) I'd prefer for there to be e.g. inputs.colmena.nixosModules.default that doesn't just supply the options (as inputs.colmena.nixosModules.deploymentOptions does), but also their implementation. I don't see (feel free to point it out) what needs to be injected there that isn't available at "any" evaluation time -- with nixops's model of resources that are also managed by the tool, that makes sense, but given that colmena doesn't "create" machines or otherwise manage resources (sensible choice IMO!) it's not necessary.

In reply to @zhaofeng:zhaofeng.li

To further expand on that, consuming the existing nixosConfigurations is problematic, since Colmena needs to insert two things into the configuration: Modules (deployment.* options and configs) as well as module arguments (name and nodes which allows you to refer to configurations of other nodes in the cluster). This is in part following the design decisions of NixOps and morph. Inserting them cannot be cleanly done in case of nixosConfigurations which contains complete, evaluated configurations rather than individual NixOS modules.

We could remove this need and make the user specify the deployment.* configs externally, outside the NixOS configuration. This is the approach that deploy-rs takes (the deploy output). The downside is two-fold:

1. The level of configuration composition possible will be limited. As an example, I set deployment.tags = [ "routers" ]; in my router module so enabling it will automatically make colmena apply --on @routers deploy to this node. Additionally, I use the added nodes argument extensively in my configuration to set up a WireGuard mesh and iBGP peerings between my nodes.
2. The effect Colmena can have on the target node configuration will be limited. For instance, Colmena creates the ${name}-key.service for each secret file defined in deployment.keys, which will no longer be possible. deploy-rs uses a deploy binary copied alongside the profile to implement activation and other features.

The end result is a level of functionality noticeably different from "normal" Colmena that would necessitate a lot of documentation changes and still be confusing to users.

1. The nodes argument doesn't require colmena though. nixosConfigurations can reference self.outputs.nixosConfigurations to get at other hosts.
2. (covers deployment.tags as well) I'd prefer for there to be e.g. inputs.colmena.nixosModules.default that doesn't just supply the options (as inputs.colmena.nixosModules.deploymentOptions does), but also their implementation. I don't see (feel free to point it out if I'm missing something) what needs to be injected there that isn't available at "any" evaluation time -- with nixops's model of resources that are also managed by the tool, that makes sense, but given that colmena doesn't "create" machines or otherwise manage resources (sensible choice IMO!) it's not necessary.

In reply to @blaggacao:matrix.org
But, I don't know if that may break the paraleval

In reply to @yuka:yuka.dev
You could just tell the users that the colmena binary has to be from the exact same version as the hive expression