(beginner) questions and clarifications

[steveej]

instead of opening one issue per question i figure we can sort them out in one. maybe i have follow-ups or new ones in the meantime.

1. is compatibility with OpenTofu and its registry viable?
2. clarifying my understanding of the mentioned missing implementation for "resource Provisioning"? is it a reference to this? would an implemention of a previsioner with terrars involve wrapping the terraform CLI execution in rust and subsequently have more rust imperative code upon success of the CLI call?

[andrewbaxter]

Thanks for asking, and those are good questions!

So first of all, aside from terrars-generate which uses terraform to contact the registry to pull the schema, there are no calls to terraform in the code currently... (I think, or if they are they're very peripheral). (Aside, the official CDK is basically the same, but they wrap up terraform commands with the generation commands to streamline it: I think that's too workflow specific so I decided not to do that).

1. Yeah, definitely. Or at least, I intend to be compatible with them, but I don't know how much they've diverged at this time. I'm using old versions still where there was no significant difference.

   I think other than the terrars-generate command which fetches the provider schema from the registry there's no actual calls to terraform in the code - it just generates configs.

   If the opentofu and terraform config schemas themselves diverge I'm not 100% sure where this will go: I'll support both in this repo (depending on the difficulty), I'll fork and maintain them both depending on the level of interest, or I'll choose to support just the one with the most momentum (opentofu?)...

2. Yeah, exactly. So just taking a quick look, I think implementation would basically just be extending structs with fields and methods to include provisioner data. Slightly more specifically:

   • Make a BuildProvisioner struct with required fields, a build method to get a Provisioner, and mutator methods to set the non-required fields on Provisioner (this sounds really similar to building resources). Since there are multiple provisioner types, this may be provisioner specific, like BuildLocalExecProvisioner. (I can't remember how I handled resource polymorphism, I think maybe resources implement a trait? So there might be a Provisioner trait here)

   • During code generation, add a provisioner field + appropriate methods to each resource that's a Vec<Rc<dyn Provisioner>> or whatever

   • Also add a Vec<Rc<dyn Provisioner>> to the schema itself with methods for non-resource provisioners?

I might be off base with some of this stuff.

All in all, it's basically adding a few structs manually with the correct types so it should be fairly straightforward and not a huge amount of work. I think there are similar "automatic" fields in resources like depends_on and lifecycle stuff, so adding a provisioners list will be done similarly.

FWIW I think the generation code is pretty straight forward, but code generation in general is fairly gnarly because of how meta it is, plus working around terraform non-orthogonalities made it gnarlier, so while it shouldn't be a big change it may be a bit difficult to navigate that code.

[andrewbaxter]

I just looked at the opentofu registry and it still looks the same to me as the terraform registry. I think it's possible that if you have opentofu installed as terraform locally it should work for now. Alternatively, it may be good to update the terrars-generate command to allow you to choose a binary to use (or split it into two commands, one that calls terraform and one that calls tofu).