And even consuming colmena without it's flake framework might feel odd, I know

If it's a legit argument: think about that in certain (big) monorepo scenarios, the flake.nix is too much of a precious space so that it cannot accomodate NxM flake-based frameworks, but only one.

And even consuming colmena without it's flake framework might feel odd, I know

If it's a legit argument: think about that in certain (big) monorepo scenarios, the flake.nix is too much of a precious space so that it cannot accomodate NxM flake-based frameworks, but only one, in order to make the life of 20%-half-hearted & reluctant nix users a tid bit easier.

And even consuming colmena without it's flake framework might feel odd, I know

If it's a legit argument: think about that in certain (big) monorepo scenarios, the flake.nix is too much of a precious space so that it cannot accomodate NxM flake-based frameworks, but only one, in order to make the life of 20%-half-hearted & reluctant nix users a tid bit easier (by maintaining intact their principled understanding of a flake.nix).

And even consuming colmena without it's flake framework might feel odd, I know

If it's a legit argument: think about that in certain (big) monorepo scenarios, the flake.nix is too much of a precious space so that it cannot accomodate NxM flake-based frameworks, but only one, in order to make the life of 20%-half-hearted & reluctant nix users a tid bit easier (by maintaining intact their principled understanding of a flake.nix - without years of special subject matter training).

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?