Terraform: Question: Is libterraform acceptable?

Created on 20 Apr 2018  ยท  4Comments  ยท  Source: hashicorp/terraform

Hi Terraform team, At first, Thanks for this great project!

I'm the author of a Terraform linter called TFLint. Although this project is accepted by many developers, it is too difficult to develop TFLint because It is necessary to re-implement Terraform's core feature (like module resolvers, configuration overrides, etc).

So, I would like to create a Go library that can partially use the core feature of Terraform (Maybe it includes some copies of this project's implementation). Will this be acceptable?

Thanks.

question

Most helpful comment

Hi @wata727! Thanks for your work on TFLint!

At the moment we are not able to guarantee that any of Terraform's package APIs are stable, since we know that we'll need to make changes to the internal APIs to support a number of forthcoming features. Currently we are making significant changes to support a new configuration language parser and interpreter, for example.

However, if you are willing to make adjustments as Terraform evolves, it is technically possible and acceptable to use vendoring to embed Terraform packages into your application. An important caveat for this is that vendoring a particular version of Terraform will probably make the linter unable to parse configurations intended for newer versions of Terraform, because the Terraform configuration loader will produce errors when encountering configuration elements it doesn't expect. This will become less of an issue over time as the configuration language stabilizes, but new configuration features are likely for a few more major releases yet.

Our current work is _particularly_ disruptive, since we are moving from the current configuration package (based on current HCL/HIL) to a new configuration package based on an improved HCL implementation, and separate loader package for installing modules and loading configuration from disk. It may be best for you to wait until the 0.12 release and then develop against these new packages, to avoid throwaway work. (These new packages are still likely to change in unexpected ways until 0.12 is released.)

A challenge with the new configuration loader is that it's necessary to know the provider and resource schemas to fully read the configuration via the "main" API, since the new loader uses these to resolve some ambiguities that we've seen cause unexpected behavior in the current implementation. This might, unfortunately, force TFlint to also interact with provider plugins in order to gather the information necessary to properly interpret the content of resource blocks. We are planning to have a command to make Terraform read schema and express it in JSON format for consumption by tools like text editors, but that may not be implemented in time for the 0.12 release.

I hope that helps to clarify the current situation. If you have further questions, please let me know!

All 4 comments

Hi @wata727! Thanks for your work on TFLint!

At the moment we are not able to guarantee that any of Terraform's package APIs are stable, since we know that we'll need to make changes to the internal APIs to support a number of forthcoming features. Currently we are making significant changes to support a new configuration language parser and interpreter, for example.

However, if you are willing to make adjustments as Terraform evolves, it is technically possible and acceptable to use vendoring to embed Terraform packages into your application. An important caveat for this is that vendoring a particular version of Terraform will probably make the linter unable to parse configurations intended for newer versions of Terraform, because the Terraform configuration loader will produce errors when encountering configuration elements it doesn't expect. This will become less of an issue over time as the configuration language stabilizes, but new configuration features are likely for a few more major releases yet.

Our current work is _particularly_ disruptive, since we are moving from the current configuration package (based on current HCL/HIL) to a new configuration package based on an improved HCL implementation, and separate loader package for installing modules and loading configuration from disk. It may be best for you to wait until the 0.12 release and then develop against these new packages, to avoid throwaway work. (These new packages are still likely to change in unexpected ways until 0.12 is released.)

A challenge with the new configuration loader is that it's necessary to know the provider and resource schemas to fully read the configuration via the "main" API, since the new loader uses these to resolve some ambiguities that we've seen cause unexpected behavior in the current implementation. This might, unfortunately, force TFlint to also interact with provider plugins in order to gather the information necessary to properly interpret the content of resource blocks. We are planning to have a command to make Terraform read schema and express it in JSON format for consumption by tools like text editors, but that may not be implemented in time for the 0.12 release.

I hope that helps to clarify the current situation. If you have further questions, please let me know!

Thanks @apparentlymart ! Your advice is very helpful :)
I guess that some problems may not be understood without developing, but I would like to develop TFLint based on the new configuration package.

Thanks again for the Terraform team. TFLint can now provide more stable features by depending on Terraform's package APIs. I will close the issue.

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.

Was this page helpful?
0 / 5 - 0 ratings