C API

[SamuelMarks]

Use-cases

• Link—statically or dynamically—with frontends (e.g., a CLI or RPC frontend written in C, or wrapped into a library that is statically/dynamically linked into another language, such as Rust)
• Contend with multicloud interfaces in other languages, Terraform is better funded and often more maintained than, e.g., Python's libcloud, Java's jclouds, and Ruby's fog.

With everything unified and made trivially multilingual through FFI, the entire elastic scaling lifecycle can be managed from a single binary. Which will [I expect] lower the barrier to entry for moving between cloud providers, initial de/provisioning, scaling, and maintenance.

Proposal

I asked about a C API for Terraform a year and a quarter ago: https://discuss.hashicorp.com/t/c-api-to-terraform-providers/14195

Years ago I wrote a wrappers around Apache Libcloud in Python for my multi-cloud abstraction libraries. It’s great, and supports 50+ different public and private clouds.

Now, I’m tossing up betwixt the different languages to rewrite the whole system in. Likely, I’ll write the bulk of it in C (C89, the old ANSI C); maybe with some configuration management done in Rust.

Unfortunately there are no good/maintained abstracted cloud [de]provisioning/upload/configuration libraries. Cursory research shows Terraform as the only [maintained & large] library written with a non-VM language. Congrats!

Are you planning to expose C-APIs; perhaps via Go’s builtin C meta-package; so this can be used from other languages?

Thanks for considering this feature

References

https://github.com/hashicorp/terraform-cdk/issues/513 told me to create an issue here

---

PS: Happy to help create these C APIs.

[jbardin]

Hi @SamuelMarks

Thanks for your interest in extending terraform! The terraform package itself is not meant to be consumed as a library. See #26418 for example, where we are working to internalize more of the Go package surface area for this reason. In other words, terraform would need to have an API at all in order to create a C interface for that API.

The plugin interface is defined in a cross-platform way in terms of grpc, and we don't anticipate that changing anytime in the near future. The interface for the core binary will continue to be the defined file formats and protocols.

Thanks!

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.