Template v2.2.0 does not have a package available - Mac M1

Terraform Providers
6

I did not encounter this error. Maybe worth opening an issue at m1-terraform-provider-helper.

7

For Terraform Installation and Successful terraform init

Steps to install terraform of your choice of version using Homebrew:

  1. brew install tfenv
  2. tfenv list_remote
  3. tfenv install
    tfenv install 1.0.9 #example
    ​​tfenv use 1.0.9 #to switch into this version

Now, while executing terraform init you might face the below error if you are working in a MAC with M1 chip in it,

Error: Incompatible provider version
│
│ Provider Terraform Registry v2.2.0 does not have a
│ package available for your current platform, darwin_arm64.

Please follow the steps given below:

  1. brew install kreuzwerker/taps/m1-terraform-provider-helper
  2. m1-terraform-provider-helper activate
  3. m1-terraform-provider-helper install hashicorp/template -v v2.2.0

What is “kreuzwerker/taps/m1-terraform-provider-helper” ?
A CLI to manage the installation of terraform providers for the Mac M1 chip.

For complete info:
https://kreuzwerker.de/en/post/use-m1-terraform-provider-helper-to-compile-terraform-providers-for-mac-m1

After following the above steps, terraform init will run successfully !!!

9 Likes
8

The template provider is deprecated, so code should be updated to use the templatefile built in function instead of the template provider data source.

1 Like
9

Hi There, this steps doesn’t work. Any other alternatives please? Has this been ever solved by now? Thanks

10

This steps doesn’t work, still throws an error. Any other alternative you may have please or has this ever been fixed by now? Thanks

11

This one really worked. Thank you :slight_smile:

12

Hi @nishant-ci

I got the same error as you. Please try the following command, which solved the problem.
I think the “.terraform.lock.hcl” file contains a checksum of the template file that M1 cannot run.

$ rm .terraform.lock.hcl
1 Like
13

I ran into this issue today after beginning to use a new M1 mac. I had a single data resource using template_file. Unfortunately, you are unable to run terraform init even after removing any references to the the provider (I imagine this has to do with the data resource still existing in the state file).

I found a hacky work around. As previously stated, the provider has been deprecated for a year which preceded the release of the M1 chip. Do not keep using this provider if at possible and instead switch to using the templatefile function.

My hack at a high level is to point Terraform to a dummy hashicorp/template binary file. This hack will only help you run terraform init so that you can migrate away from the provider. Otherwise, you will need to build the provider yourself locally.

The hack in question:

#!/usr/bin/env bash

set -x
# some variables used through out
provider_name="template"
provider_source_address="registry.terraform.io/hashicorp/${provider_name}"
provider_version="2.2.0"
all_providers_dir=$(mktemp -d)
rcfile=$(mktemp)

# making the dummy provider
dummy_provider_dir="${all_providers_dir}/${provider_source_address}/${provider_version}/darwin_arm64"
mkdir -p "${dummy_provider_dir}"
touch "${dummy_provider_dir}/terraform-provider-${provider_name}_v${provider_version}"

# making terraform.rc file to point to dummy provider
cat > "${rcfile}" <<EOF
provider_installation {
    filesystem_mirror {
        path = "${all_providers_dir}"
        include = ["${provider_source_address}"]
    }
    direct {
        exclude = ["${provider_source_address}"]
    }
}
EOF

# running Terraform with dummy provider
TF_CLI_CONFIG_FILE="${rcfile}" terraform init

I then ran terraform state rm data.template_file.name for all relevant offending resources.

1 Like
14

If you have a configuration that was previously working on darwin_amd64 (that is, macOS on Intel chips) then I’ve heard that it typically works okay to run the darwin_amd64 version of Terraform under Rosetta emulation just long enough to remove the obsolete provider – darwin_amd64 Terraform CLI will install and run darwin_amd64 providers – and then you can switch back to using the native darwin_arm64 port of Terraform CLI and providers once you’ve completed that update.

Once you no longer have any data "template_file" ... blocks in your configuration anymore you can run terraform apply or terraform apply -refresh-only to create a new state snapshot that doesn’t refer to that provider, after which you will no longer need to use the darwin_amd64 port.

You may need to also use newer versions of other providers to get darwin_arm64 compatibility, depending on how long ago you last upgraded them. If so, you can also complete those upgrades also using the darwin_amd64 port under emulation. As long as your .terraform.lock.hcl file selects a sufficiently-new version and includes all of the official cross-platform checksums for that version then darwin_arm64 Terraform should be able to install and use it.

15

I’d love to be able ot use the @apparentlymart method, since it seems like the cleanest solution to me. I’m happy to switch to the templatefile() function.

So I’ve replaced all instances of the template_file provider with the templatefile() function. I’ve then opened a Rosetta terminal and confirmed that it’s running under emulation (arch responds with i386). When I use terraform init, though, I still get the no package available for your current platform, darwin_arm64 error.

Does the fact that I’m using Terraform Cloud factor into this at all? I tried removing the template provider block entirely from my .terraform.lock.hcl and that changed nothing. I’m kind of stumped at this point. I thought I knew what the problem was, but this isn’t behaving like I’d expect.

1 Like
16

So the solution in my case was to make the template_file to templatefile() change on the Intel Mac and apply the changes so that Terraform Cloud no longer needed the provider. Then I was able to run terraform init again and the lockfile was updated, removing the provider. I checked that in on the Intel Mac and fetched it on the M1. Now terraform init on the M1 Mac works fine.

It’s pretty much what @apparentlymart suggested, just using a real Intel Mac instead of emulation. Thanks for explaining what the underlying issue was!

2 Likes
17

Hi Nick, I had the same problem after switching to templatefile(), and it terraform init still trying to download template provider, it turns out in my current state still has the data.template_file resources, what I have done is to remove them from the state file by getting all the template_file resources from the current state by running
terraform state list | grep data.template_file
then remove one by one using
terraform state rm <resource_name>

18

This worked for me. Thank you!

19

None of the prior steps helped but doing the following did for me:

TFENV_ARCH=amd64 tfenv install 1.1.9

I have an M1 Mac Chip and specifying the arch to be amd64 worked

5 Likes
20

A fix i found was after running:
brew tap hashicorp/tap
brew install hashicorp/tap/terraform

i had to also run this to get it to register the new arm64 version
brew link --overwrite -terraform

Which does:
/opt/homebrew/bin/terraform → /opt/homebrew/Cellar/tfenv/3.0.0/bin/terraform

I’m running on darwin_arm64
Terraform v1.3.0

21

By giving a try to these different answers, here is what I ran to install a Terraform 1.3.3 version that works under my Mac M1 and get rid of this error:

brew uninstall terraform
brew install tfenv
TFENV_ARCH=amd64 tfenv install 1.3.3
tfenv use 1.3.3
2 Likes
22

In my case helped use newer version 1.3.4

brew uninstall terraform
brew install tfenv
TFENV_ARCH=amd64 tfenv install 1.3.4
tfenv use 1.3.4
1 Like
23

This worked for me. Thank you!

24

I agree with @stuart-c - For those landing on this article in 2022/2023, please, make sure you stop using the Template Provider as it has been deprecated.

Instead, use templatefile.

25

working in latest version 1.3.7

brew uninstall terraform
brew install tfenv
TFENV_ARCH=amd64 tfenv install 1.3.7
tfenv use 1.3.7
1 Like