`go-getter`'s

GetFile

is then used to get the binary. This is broken with TF

>= 1.8.2

as a License.txt file is also included

Any reason why we can't tweak

go-getter

usage to deal with multiple files? I like

hc-install

and use it a lot of our internal tooling; just curious if tweaking existing

go-getter

usage to not care about extra files (of any kind) and keeping the code usable between TF and Tofu wouldn't be a bigger net benefit? 1. Grab zip 2. Extract the zip to tmp dir 3. Expect a file named

terraform

or

tofu

in the tmp dir 4. Copy that binary file into place 5. Wipe the tmp directory any future zip file changes or additional files would be ignored 🙂

I guess it depends on what outcome you are wanting. There's a couple of relevant draft PRs: • PR to change usage to

GetAny

- https://github.com/runatlantis/atlantis/pull/4478 • PR to add OpenTofu support - https://github.com/runatlantis/atlantis/pull/4499 This comment seems to suggest that a possible goal is to remove the "package-manager" aspect from Atlantis. • Current usage: Use

terraform-switcher

lib to get all available TF versions, put them into slice, sort, cycle through checking versions against constraint • Proposed

hc-install

usage: Let

hc-install

determine the version to download, and also let it download it The

hc-install

approach has the benefit of eliminating other areas (such as getting a list of all TF versions, manually checking constraints for it) - it doesn't just touch the download/unzip part. It also wouldn't be a 1-1 mapping of logic between TF vs OpenTofu - the WP PR for OpenTofu support needs completely different logic to "fetch" the list of available versions as there is not support for it in

warrensbox/terraform-switcher

- https://github.com/runatlantis/atlantis/blob/df1dbbad11b0413e0f204394bf16b4ed2c52a214/server/core/terraform/terraform_client.go#L690-L725 If we kept the current implementation for TF and Tofu, the only thing that would be kept the same is the downloading/unzipping the ZIP file I believe?

I could 💯 get behind not having any of this in Atlantis, and letting the community use something like tfenv in their workflows to control their TF versioning usage - and possibly baking

tfenv

or similar into the Atlantis image instead for convenience

I agree too, and I think it is definitely something Atlantis should try and head towards, but that's no small-feat and won't be done for a while - it is still only n hypothetical stage by the sounds of it? I feel like it would be a mistake to not take "easy-wins" or chances to simplify the current codebase/logic because of a future aspiration though - advancement of something in-use shouldn't stop just because it may be removed in the future?

100% agree with that 🙂 I'm not opposed to a "fix this before we remove it later, maybe" approach

Yeah that's something I was wondering too - I think regardless of whether

hc-install

PR goes ahead, go-getter usage will need to be changed to

GetAny

instead of

GetFile

like in the draft PR to unblock

>=1.8.2

assuming we would have 3 code paths

TF hc-install

,

TF go-getter

custom +

Tofu go-getter

otherwise

^ Yeah that might be a good point. I wonder how difficult it would be to fork

hc-install

and add support for custom URL and/or OpenTofu support 🤔 (outside scope of Atlantis, just curious) But yeah, I think sorting go-getter to work with 1.8.2 should be done first and evaluate from there maybe?

the

remove TF package manager of atlantis

is still a conversation we need to decide on but there are a few of us that think it will be better in the long term @Luke Massa @RB @Rui @Dylan Page

At first glance, it doesn't seem too difficult to add support for custom URL to hc-install? Made a POC PR https://github.com/hashicorp/hc-install/pull/203

Because

hc-install

is created and maintained by hashicorp (call me cynical), if opentofu is getting downloaded through that pipe, it would be fairly easy for them to “break” it by mistake

Oh yeah, I 💯 agree with that ^. My main thoughts were: 1. Try and get custom URL support added into hc-install. This would then cover Terraform downloads from both their release URL and custom ones. 2. This wouldn't allow OpenTofu support in hc-install - that would require a lot more work (I don't think Tofu have an API URL for releases, just github releases by the looks of the draft PR) 3. If Tofu wanted in the future, they could fork hc-install and adapt it, or make their own downloader If we get custom url support for TF into hc-install though, it should work for Default URL TF and Custom URL TF - meaning any future support for Tofu would only result in 2 code paths rather than 3 (wouldn't need

go-getter

for custom URL downloads of TF, just for Tofu) - https://atlantis-community.slack.com/archives/C04ES70Q6E8/p1714755412078889?thread_ts=1714753649.673719&cid=C04ES70Q6E8