Enhance provider plugin initialization output with conflicting provider constraints

[trutled3]

Terraform Version

1.9.1

Use Cases

When consuming multiple child-modules managing provider version constraints becomes challenging. Presently, the output of the provider initialization just prints

Finding hashicorp/aws versions matching "~> X.Y.Z"...

When Terraform detects multiple constraints for the same provider it will list out the detected constraints for example,

Finding hashicorp/aws versions matching ">= 4.48.0, ~> 5.0"...

The use case I have is the constraints conflict and there is not a matching provider version to be found, it can be time consuming to determine which child module is constraining to what version of a provider.

Attempted Solutions

To determine the constraint for each child module you can inspect each module folder within the .terraform/module directory for the constraints. This can of course be scripted with tools like grep/find/etc.

Proposal

A proposed solution for this would be to enhance the output within the Initializing provider plugins... output to include the module in which the detected constraint is located similar to the output of the Initializing modules... stage of a Terraform init. For example,

A single version contsraint:

Finding hashicorp/aws versions matching "~> X.Y.Z" for root module....

Multiple version constraints:

Finding hashicorp/aws versions matching ">= 4.48.0" for root module, "~> 5.0" for .terraform/modules/moduleA ...

References

No response

[jbardin]

Hi @trutled3,

Thanks for filing the issue. The terraform providers command shows all of the provider requirements for the configuration. Does that command give you the information you are looking for?

Thanks!

[trutled3]

Hi @jbardin , the terraform providers command does work once you have initialized Terraform, however this command can not yet be used my use case where the Terraform init stage fails due to incompatible provider constraints. When I run terraform providers prior to initializing Terraform, I get the following errors for the child-modules.

│ Error: Module not installed │ │ on main.tf line 14: │ 14: module "example" { │ │ This module is not yet installed. Run "terraform init" to install all modules required by this configuration.

[jbardin]

Thanks @trutled3, that result can be confusing. The init command is somewhat overloaded, doing multiple things at once which can make the errors hard to understand. I think however that the provider error should be emitted after all the modules have been installed already. Does following up with terraform providers immediately after the failed init not work?

In this situation you could also use terraform get to only update the modules, which would allow you to then inspect the problematic provider constraints.

[trutled3]

I see. Thank you for that clarification @jbardin . I can confirm that running terraform providers after the terraform init fails.

[trutled3]

Could an acceptable enhancement be to call to the terraform providers logic be triggered upon error of the installation of the providers and print the output similar to the terraform providers command? Alternatively, an enhancement to the error message notifying the practitioner to run the terraform providers command as a tip to resolve the incompatible constraints?

[jbardin]

Thanks for confirming. We will have to evaluate which route to take based on the current cli architecture, but we should be able to improve the UX here to help pinpoint the errors.

Thanks!

[apparentlymart]

When we originally implemented terraform providers it was written intentionally to work when the provider installation step of terraform init fails, and then the error message from terraform init encouraged running it for more information on where each requirement was coming from.

That was intended as a compromise to avoid producing an overwhelmingly long error (which we've learned from experience that many people just don't read at all) but still give a clear path to more information for a reader that decides they would benefit from it.

It seems like we regressed this at some point if terraform providers isn't working even though all of the modules have already been installed. The modules being installed should be the only prerequisite for this command to work, because the module source code is where the provider requirements come from.

I'm not sure at what point this stopped working, but if we decide to make it work again (as opposed to choosing a different solution) it'd probably be worth adding an e2etest case for this situation to reduce the chance of it becoming broken again in future.

[trutled3]

@apparentlymart - I wanted to clarify that the terraform providers command does work when the terraform init fails. Thank you for that detailed historical context around the error message!

[jbardin]

Thanks for the clarification @trutled3. In that case I think we can proceed by adding the terraform providers suggestion to this situation too. The error generated here is kind of generic, but adding the suggestion to the default case is probably helpful most of the time, and at worst it's not detrimental, so I don't think we need to refactor the error handling entirely.

[github-actions[bot]]

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.