Open valentindeaconu opened 2 years ago
Thanks for this request!
Here is a list of currently open issues that can be approached or even solved (at least partially) with this feature:
Also, I found an old discussion regarding a similar implementation for this feature in the issue https://github.com/hashicorp/terraform/issues/8002.
@crw is there any news on this feature request?
No updates. We prioritize based on upvotes, although the list of linked issues also helps when considering the impact of the feature. We also categorize issues and attempt to address them when working on those areas of the code.
Terraform Version
Use Cases
Working with Terraform on large-scale projects or mono-repositories with a lot of duplicates can become really overwhelming. For example, updating a module version or refactoring the name of the AWS profiles. In this feature request, I propose an idea of introducing init-time constants (values that can be evaluated at init-step) which can help us (Terraform developers) to follow the DRY principles and also can reduce a lot of hardcoded values.
Attempted Solutions
For example, to define a module, the only possible way is:
If we have two instances of the same module:
Of course, we can use a
for_each = toset(["1a", "1b"])
to avoid repeating ourselves, but this problem can become more complex: what if we have 2 different Terraform projects, with two different backends, hitting different accounts? Thefor_each
workaround no longer works. So we will end up with two actual module blocks copied in both places. The problem occurs when we want to bump the module version. We will have to update both places.This problem can be solved outside of Terraform by introducing a wrapper (e.g. Terragrunt) or by using a dependency updater (e.g. RenovateBot) (for this use-case only).
There are a lot of use cases where we can use those constants to avoid hardcoding values -
provider
blocks,terraform
blocks (providers versions, Terraform version, backends), modules, etc.Proposal
My suggestion to overcome this issue is to introduce init-time constants. The constants will be defined totally the same as the variables:
And then used in code as:
Of course, the main point here is supporting them exactly the same as the variables:
-const
flag;TF_CONST_
prefix environment variable;More explicitly, they will behave like variables, the only difference here being the time when they are evaluated (pre-init, instead of post-init).
References
22088
31993