Add support for other providers sub-commands

[philnielsen]

Right now the only providers command supported is providers schema, there are several more provider commands available now and support for them would be greatly appreciated.

I would consider adding myself if you all are open to contributions for such a feature.

[radeksimko]

Hi @philnielsen
In general we are open to contributions.

When it comes to adding support for new (sub)commands I'd usually ask first whether there's a real use case you have in mind (or know of) for these in the context of automation?

While most commands make sense in automation, some commands are meant to be used by humans - e.g. terraform console, terraform login and terraform logout (at least in the current state).

There are some commands which are border-line at first sight but we decided to include them because real use cases came up - e.g. 0.12upgrade or 0.13upgrade.

Do you have some ideas on how you'd use providers lock or providers mirror in any program of yours?

[philnielsen]

Thanks for taking a look @radeksimko

Specifically my use case is we currently automatically bootstrap new terraform states for teams without having to know anything about our s3 backend setup. providers lock is the useful add here, because we want to be able to generate a .terraform.lock.hcl file for teams after instantiating a generic terraform setup with the AWS provider configured.

As of TF14, now teams (who are mostly using darwin systems for development) have to remember to manually run terraform providers lock -platform=linux_amd64 -platform=darwin_amd64 otherwise our CI system (which is linux container based) won't work when they run for the first time. i'm hoping to add provider lock command to the boostrap cli (closed source for now) to pre-fetch these checksums as part of the bootstrap so there is one less command to run manually.

[radeksimko]

Thank you for describing that use case - that sounds reasonable. Feel free to send a PR for providers lock.

Do you have a use case in mind for the mirror subcommand also?

Either way I'd suggest keeping the PRs narrowly focused - 1 command per PR is ideal.

[philnielsen]

I don't currently have a use case for mirror, but i'll hop in and work on that PR for lock when I get a chance!

[radeksimko]

lock command was added in #203 and because there isn't any known use case for mirror within automation I'm going to close this issue but feel free to open a new one if you find a use case!