search

hashicorp / terraform

Terraform enables you to safely and predictably create, change, and improve infrastructure. It is a source-available tool that codifies APIs into declarative configuration files that can be shared amongst team members, treated as code, edited, reviewed, and versioned.
https://www.terraform.io/
Other
42.4k stars 9.5k forks source link

Support development of provider SDKs in languages other than Go #32748

Open cfbao opened 1 year ago

cfbao commented 1 year ago

Terraform Version

Terraform v1.3.0
on windows_amd64

Affected Pages

https://developer.hashicorp.com/terraform/plugin/terraform-plugin-protocol https://github.com/hashicorp/terraform/tree/main/docs/plugin-protocol

What is the docs issue?

There's a startup & handshake protocol for Terraform plugins. It's mentioned in the repo:

The startup and handshake protocol is not currently documented. We hope to document it here or to link to external documentation on it in future.

This creates a gap that prevents custom implementations of Terraform plugin framework (potentially in a different programming language).

Proposal

Document the Terraform plugin startup and handshake protocol.

References

No response

apparentlymart commented 1 year ago

Hi @cfbao! Thanks for this feature request.

Currently the two libraries written in Go are the only supported way to write a Terraform provider. Although it would be nice to support development in other languages eventually, developing the protocol and the official server implementations together allows for easier evolution for new features, and the new framework is still growing so the development focus is there.

For an unrelated side-project I defined a subset of this handshake protocol that happens to be Terraform compatible today, which might be a useful reference but I would caution that Terraform is not guaranteed to remain compatible with what I documented over there; I wrote that up for something totally unrelated to Terraform and so Terraform might change in future in ways that make it diverge from my third-party "rpcplugin" design.

I'm going to broaden the scope of this issue to be about supporting plugin development in languages other than Go, since that seems to be the original goal that led you to this proposal and I think that's the decision that would need to be made before it would make sense to explicitly document the handshake protocol and thereby encourage development of SDKs in other languages.

Thanks!