hashicorp / terraform

Terraform enables you to safely and predictably create, change, and improve infrastructure. It is a source-available tool that codifies APIs into declarative configuration files that can be shared amongst team members, treated as code, edited, reviewed, and versioned.
https://www.terraform.io/
Other
42.71k stars 9.55k forks source link

Allow deprecation of a module #5949

Open radeksimko opened 8 years ago

radeksimko commented 8 years ago

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:

deprecated {
  message = "This module is deprecated, see alternative at github.com/.../..."
}

which could cause terraform get (and possibly apply) to display predefined message in the terminal

WARN: This module is deprecated, see alternative at github.com/.../...
tomelliff commented 7 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/.../..."
  }
}
ghost commented 5 years ago

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 👌

sergei-ivanov commented 3 years ago

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)).

ghostsquad commented 3 years ago

is this on the roadmap?

spacefuntus commented 2 years ago

Any update on this ? Is Hashicorp working on this feature ?