What’s the current attitude to plugins/providers built in programming languages other than Go, and is there any hope of adding official frameworks/SDKs for these in future?
I’m relatively new to TF, but have a lot of experience with AWS CloudFormation & CDK. I’ve often had to write CloudFormation custom resources in the past to bridge (usually temporary) gaps in CFn coverage… And although that system has its fair share of problems it does enable us to write custom resources in a range of high-level languages - which I really appreciate since most of my work is usually in Python & TypeScript. Picking up Go from scratch seems like a heavy lift just to hack together IaC integration for a new CRUDL API.
As I understood so far (from exploring the official terraform-plugin-framework
, the third-party Python-TF plugin framework):
- Under the hood, a provider/plugin is a standalone process implementing a gRPC server, but the TF docs emphasise the plugin framework (based on
terraform-plugin-go
) as the point of integration rather than that low-level RPC interface. I think the RPCs are documented here? - Terraform bakes in an assumption that a plugin is a standalone executable binary, which Go makes significantly easier than Python & JavaScript - but there are packaging options out there for both…
- Python-TF caveats makes some comments about assumed reluctance of HashiCorp to entertain partnering with plugins that are built on more custom frameworks for the registry.
From the fact I couldn’t find loads of existing threads here or GitHub issues asking for additional language bindings already, I assume the demand’s not been evidenced yet to commit to supporting more SDKs. The most realistic route seems like it’d be to build adoption of providers based on 3p-maintained frameworks first, to prove interest?
So I’m wondering if we could get clarity on whether HashiCorp really would resist or block a plugin/provider from partnering with the registry if it was based on a direct RPC integration rather than the proper SDK/framework (but was still able to provide standalone executable files as expected)?