This means that we can no longer directly import hashicorp/terraform as a Go library. As a result, it will be difficult to support future Terraform releases.
The current implementation of the tfschema depends on the following packages:
plugin/discovery: Find a plugin
plugin: Start a plugin client for protocol v5
plugin6: Start a plugin client for protocol v6
providers: Call provider's APIs
configs/configschema: Decode API respose types
I investigated some alternatives such as terraform-plugin-go, terraform-plugin-sdk, etc., but these are provider development libraries and do not include the grpc client side implementation. Unfortunately, the grpc proto file and the Go code generated from it are also internal and cannot be imported directly. If we would reimplement the provider client, it would be possible to copy and reuse the proto file under the original MPL license. However the problem is not only for the provider client, but also the implementations of discovering and starting plugin and decoding types. So if we go this direction, it would need to reimplement lots of the Terraform internals.
Historically, the tfschema has been written before the official providers schema command was added, but now it's a reasonable option. A downside of this option is only that it requires initializing a backend to access a tfstate, which is needed to detected dependencies for working destroy action correctly.
Typically accessing the backend requires credentials for cloud providers, it is not desirable for the tfschema. It might be avoided by executing terraform init in a temporary directory and caching provider's binary, but invoking a completion probably becomes slow.
I found an unofficial Terraform provider client implementation: https://github.com/magodo/terraform-client-go
The license is MPL2. I looked at the dependency graph, and it is used by Azure/aztfexport.
The Terraform v0.15.4 moved all Go packages to internal. https://github.com/hashicorp/terraform/pull/28723
This means that we can no longer directly import hashicorp/terraform as a Go library. As a result, it will be difficult to support future Terraform releases.
The current implementation of the tfschema depends on the following packages:
I investigated some alternatives such as terraform-plugin-go, terraform-plugin-sdk, etc., but these are provider development libraries and do not include the grpc client side implementation. Unfortunately, the grpc proto file and the Go code generated from it are also internal and cannot be imported directly. If we would reimplement the provider client, it would be possible to copy and reuse the proto file under the original MPL license. However the problem is not only for the provider client, but also the implementations of discovering and starting plugin and decoding types. So if we go this direction, it would need to reimplement lots of the Terraform internals.
Another option in my mind is to use Terraform as a CLI and parse the output of the
terraform providers schema -json
. https://www.terraform.io/docs/cli/commands/providers/schema.htmlHistorically, the tfschema has been written before the official
providers schema
command was added, but now it's a reasonable option. A downside of this option is only that it requires initializing a backend to access a tfstate, which is needed to detected dependencies for working destroy action correctly.https://github.com/hashicorp/terraform/issues/24261
Typically accessing the backend requires credentials for cloud providers, it is not desirable for the tfschema. It might be avoided by executing terraform init in a temporary directory and caching provider's binary, but invoking a completion probably becomes slow.