generate by reflection?

[KiaraGrouwstra]

hi there!

i noticed the implementations here seem maybe a bit verbose to the point of manually wrapping much of the upstream TF providers, making me wonder if perhaps more of that could already be inferred from the TF providers themselves.

this should hopefully limit maintenance surface, while making it easier to keep the code up to date as the TF providers publish updates.

if it helps, both nixops4 as well as fediversity's nix-tf-schema have done stuff around such reflection-based generation of nix modules from TF resources before.

[bitbloxhub]

Tofunix also generates module system schemas from Opentofu providers, in case anything from there helps.

[aforemny]

Hi @KiaraGrouwstra, hi @bitbloxhub, thank you for this! I remember encountering this design decision, and just took the present route without much consideration in order to get the first implementation out there. I agree though, that we should probably do this, for the reasons that you have stated. I was initially wondering whether Terraform's schemas provide any guarantee on the quality, which would directly translate to the quality of the options layer we have in Nix. Like, is it allowable to just type everything anything in Terraform, thus degrading our API? Given there seems to be positive experience with exactly this, I find it likely that I will agree, and that we will switch to reflection based generation of module options. Thank you very much for opening #6. I will have a look as soon as time permits!

[KiaraGrouwstra]

@aforemny thanks! as for upstream quality, i agree there are no guarantees there, but so my position here is, if upstream types are too loose, we may want to fix those upstream, rather than duplicate and risk drift.