Ability to specify the terraform architecture to install on darwin platform

[edmondsiu0]

Is your feature request related to a problem? Please describe. The terraform configuration used by my organisation relies on a deprecated provider that only provides binary in darwin_amd64 architecture.
During the upgrade process to make our code ARM compatible, I was testing the code on my local machine to ensure the existing code is known-good.
To do that I fetched the code, used tfswitch to switch to the intended version and ran Terraform init.

I then discovered while tfswitch is capable of identifying the platform that I'm on (darwin_arm64) and fetches the corresponding binary, I was not able to override this behaviour to force it to fetch darwin_amd64.

Being unable to fetch darwin_amd64 means I have to manually download the binary and move it into place before I can resume testing.

Describe the solution you'd like tfswitch should accept an additional optional argument along with version, when supplied tfswitch should override the default architecture decision and install the specified architecture instead.

For example:

tfswitch 1.5.6 darwin_amd64

Describe alternatives you've considered I have manually downloaded and linked the binary on my local machine.
This is the method I'd use without this feature in place, and there is no alternatives right now.

Additional context Mac OS on ARM is capable of running darwin_amd64 binaries (with Rosetta 2 translation).
Terraform fetches provider based on it's own architecture, which means Terraform code that uses providers with only darwin_amd64 binary can still be executed on Mac, as long as Terraform binary is also running on darwin_amd64 architecture.

[yermulnik]

Thanks for describing your use case. While I'm not sure this request is something tfswitch was meant for (tfswitch tries its best to detect user's platform and download terraform binary of corresponding type and arch to reduce user-end toil to bring as much smooth user experience as possible), we're open for contributions and will consider any PR that brings in new feature that can help improve UX even further. Along with that I have to admit that this project unfortunately is in sort of abandoned state at the moment and most probably there will be no PRs merged in near future 😢

ps: I'm closing this issue at this moment. Please feel free to come up with PR (or someone else can do that if the requested feature is interesting for others).

[tymik]

I would also be happy to see such feature - mostly because of old template provider, that doesn't provide a compiled binary for Mac, as it was archived almost 4 years ago, but I have a project where it is still used.

The workaround I've found is for tfenv and I'm happy using tfswitch, so I'd love to keep using it - but for now I don't know how to overcome the arch issue.

@yermulnik any chances you would reconsider this? I would be really happy if it could get incorporated into tfswitch. Unfortunately I'm not familiar with Go, so it's unlikely I can provide a PR for that :(

P.S. I know this would be a feature to allow a workaround instead of resolving the actual problem, but it is what it is - I will not easily refactor the codebase to get rid of the deprecated provider (although I'd like to do it eventually) and I need to start working with it.

[yermulnik]

@warrensbox @MatthewJohn @MatrixCrawler @crablab @jukie What do you think?

[yermulnik]

The terraform configuration used by my organisation relies on a deprecated provider that only provides binary in darwin_amd64 architecture.

By the way, is https://github.com/kreuzwerker/m1-terraform-provider-helper what should help resolve this issue?

[MatthewJohn]

I think it makes sense. Though, if you have an amd64 binary on a arm64 mac, how can it be executed? Does it require some other application to provide a compatibility layer? (I guess I'm somewhat alluding to is, if you need a compatibility layer to run the amd64 version, can you run the amd64 version of tfswitch - but I guess it doesn't help if you just want the amd64 of a particular verison of tfswitch)

We'd need to consider the options around the cached terraform binaries. Maybe we could append the architecture to the binary name, if the architecture doesn't match the system one?

[yermulnik]

I think it makes sense.

Does it make sense to re-open this issue?

Both use cases from this issue look to be requests for workaround for the legacy/outdated TF providers. The https://github.com/kreuzwerker/m1-terraform-provider-helper should suffice to overcome "issue" that both reporters encounter. I can see quite a limited use case for a custom arch. So the convenience of this option is quite limited (I mean target audience), while I also see this is a good option though 🤷🏻 Given its specific and to reduce code changes, we may provide only env var for the arch to be customized I guess. @MatthewJohn WDYT?

[tymik]

The terraform configuration used by my organisation relies on a deprecated provider that only provides binary in darwin_amd64 architecture.

By the way, is https://github.com/kreuzwerker/m1-terraform-provider-helper what should help resolve this issue?

Possibly yes, but I need to follow a limited trust rule and I don't know that tool - I've first seen it when looking for a workaround for mac (as e.g. linux doesn't have this issue, the binary for the provider is available).

And I know we should update the code to get rid of the deprecated provider, but for now it is what it is. I will understand if you won't pick it up to improve life for minority, but I will greatly appreciate if, by any chance, you do.

If I had any golang proficiency, I would even try to prepare a PR, but for now it seems to me like an impossible task :(

[yermulnik]

Possibly yes, but I need to follow a limited trust rule and I don't know that tool - I've first seen it when looking for a workaround for mac (as e.g. linux doesn't have this issue, the binary for the provider is available).

FWIW: I, more or less closely, know a dozen of people who employed that helper provider to overcome the issue with legacy providers when it arose back in the day. Never heard of any security incidents or any other difficulties with that. Of course, I don't say "I vouch" as it's still up to you to consider your security posture — but from the common sense point of view tfswitch and https://github.com/kreuzwerker/m1-terraform-provider-helper are of the same nature, both are OSS tools to help community with the everyday tasks.

[yermulnik]

I'd also like to admit that, while agreed in general, we haven't met the decision on whether this feature is indeed demanded by the community in particular. Please use regular for GH way of voting by adding thumb-ups to the original post and ping us when this hits some descent number of likes — we'll re-visit this request. Thanks.

Until then I think the resolution for such requests might be to download manually required arch/version of TF and drop it into ~/.terraform.versions/ dir by following binary files naming convention used in that dir — tfswitch does its best to not re-download already downloaded binary files for TF versions.

[tymik]

I'd also like to admit that, while agreed in general, we haven't met the decision on whether this feature is indeed demanded by the community in particular. Please use regular for GH way of voting by adding thumb-ups to the original post and ping us when this hits some descent number of likes — we'll re-visit this request. Thanks.

Does voting make any sense for the issue that is closed? Perhaps it could be re-opened? I'm not sure if people vote in closed issues.

[MatthewJohn]

I agree - sorry I was going to comment about this. Maybe we could have a label for community vote?

[yermulnik]

Makes sense. Re-opened.