So right now I'd imagine a workflow similar to:

1. Terraform creates the infrastructure
2. Terraform generates a json output of that infrastructure
3. nix/colmena consumes it to generate the appropriate config (I'd guess mainly modifying the deployment-keys, while keeping the larger portion of the config in "pure" config files) - this might require impure flake evaluation
4. colmena deploys the config

So let's say:

1. apply. HostA IP = 1.1.1.1
2. destroy
3. apply. HostA IP = 1.1.1.2

well... just like I was expecting, it doesn't work. 😕
In my flake, I have:

let inventory = builtins.fromJSON (
      builtins.readFile
      (
        pkgs.runCommandLocal "terraform-inventory" {
          src = ./.;
        } ''
          export PATH=${self.outputs.devShells.${pkgs.system}.default}/bin:$PATH
          bash $src/ansible/inventories/terraform.sh > $out
        ''
      )
    );
in colmena = { ... } # Stuff that parses the inventory and generates machine info

The results, as I was expecting:

> colmena build
warning: Git tree '/var/home/yajo/prodevel/moduground' is dirty
[INFO ] Using flake: git+file:///var/home/yajo/prodevel/moduground
[INFO ] Enumerating nodes...
warning: Git tree '/var/home/yajo/prodevel/moduground' is dirty
building '/nix/store/pa4n1x0ncgw669zyksz89kwflpr51nl8-terraform-inventory.drv'...
╷
│ Error: Backend initialization required, please run "terraform init"
│ 
│ Reason: Initial configuration of the requested backend "http"
[...]

Basically it means that it's trying to build that inventory as a normal derivation, in isolation. Thus, it doesn't get the necessary environmental secrets that Terraform uses to access its state, and fails.

The dynamic inventory should be evaluated outside of the nix expression, and maybe passed in as an argument. But my guess is that this would be common enough so as to colmena needing to add support for it out of the box somehow, right?