Open radeksimko opened 8 years ago
With terraform
configuration blocks being used to drive versions required to use a module would this make more sense to live inside that block?
I was thinking something like:
terraform {
required_version = ">= 0.9"
deprecated {
message = "This module is deprecated, see alternative at github.com/.../..."
}
}
Any ideas on when / if this is going to be deployed? This would be superbly helpful for correctly implimented modules that use Git for their references.
We're currently trying to deprecate some old modules, and allow people to move to new ones without implimenting breaking changes to force them to. This would be 👌
I would love this to be implemented in some way, alongside deprecations for variables and outputs (#18381).
In my opinion, deprecation message for the module does not quite fit semantically into terraform
configuration object. And creating a separate top-level element for deprecation does not allow for extension.
Perhaps a new top-level configuration element is needed to represent module meta-data, which may include deprecation warnings or anything else that might be deemed useful in the future (e.g. information about module author(s) or licence(s)).
is this on the roadmap?
Any update on this ? Is Hashicorp working on this feature ?
Since modules can become a critical part of an application/infrastructure and there can be more users using them than is the other capable of tracking it would be useful to have a mechanisms of deprecating a module.
Essentially I'm thinking of something like this:
which could cause
terraform get
(and possiblyapply
) to display predefined message in the terminal