CLI option to update versions.tf file

[zachwhaley]

I would like an easy way to update my versions.tf when new providers are added.

Current Terraform Version

Terraform v0.15.0

Use-cases

In the case where I've just added a new provider (e.g. hashicorp/time) to my terraform code, I would like an easy way to set the minimum required version (e.g. the current version I just used) of that provider in my versions.tf file.

Attempted Solutions

I believe the preferred solution at the moment is to use the .terraform.lock.hcl file, but we are not using this file at the moment due to cross-platform deployment issues (which may has already been resolved 🤷🏻 )

Proposal

It would be nice if there were a command, similar to the 0.13upgrade command, that could take the providers I am using and write them to the versions.tf file with at least current versions set, so that I do not have to do this manually.

E.g.

I have a versions.tf.

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 3.0"
    }
    time = {
      source  = "hashicorp/time"
    }
  }
  required_version = "~> 0.15.0"
}

I run terraform providers update and the versions.tf file is modified to include missing providers and minimum required versions.

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 3.0"
    }
    time = {
      source  = "hashicorp/time"
	  version = ">= 0.7.0"
    }
    null = {
      source  = "hashicorp/null"
	  version = ">= 3.1.0"
    }
  }
  required_version = "~> 0.15.0"
}

References

Similar to

• CLI option to display outdated providers #26920

[apparentlymart]

Hi @zachwhaley! Thanks for sharing this use-case.

As you suspected, the intent here is that .terraform.lock.hcl is where you'd record exactly what you're currently using, while required_providers is intended more for declaring what a particular module is compatible with.

Filling in the currently-selected version as a minimum would therefore have the (possibly minor) disadvantage of probably giving a quite pessimistic answer about what's required most of the time, potentially forcing users of the module to take a newer provider version than they would actually have needed to use the module.

With that said, that's a concern more for shared modules than for root modules, because in shared modules this is a mechanism for the module maintainer to communicate to the caller about what is needed, but for a root module the person maintaining the whole configuration is likely the same as the person maintaining the root module.

I expect that for the immediate future we'd prioritize fixing the remaining quirks that make the lock file hard to use rather than adding another mechanism alongside it, but I do agree that there's a potential something here for helping to manage version compatibility declarations even in an ideal world where the lock file were functioning perfectly for everyone, so I think we'll keep this here to reflect on once we've got the lock file in good shape and can thus have a better sense of what's missing that something like this proposal could help address.

Thanks again!