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

Hi

Any idea how I can fix this error, when performing terraform init?

template v2.2.0 does not have a package available for your current platform, darwin_arm64

My terraform version is:

Terraform v1.1.4
on darwin_arm64

Thanks!

Did you get it working? I have same problem

Hello,

The Template provider was deprecated and archived before the existence of M1 (darwin_arm64) releases.

The closing issue in the repository has examples of the replacement functionality in Terraform 0.12 and later: https://github.com/hashicorp/terraform-provider-template/issues/85. If you must use the provider on M1 hardware, you will either need to run Terraform as an amd64 binary under rosetta, or build and install the provider manually. See CLI Configuration: Provider Installation for details concerning the manual provider installation process.

1 Like

I managed to get it working by doing the following:

  1. Remove any existing Terraform binary (/usr/bin/terraform and/or /usr/local/bin/terraform)
  2. Install m1-terraform-provider-helper
    2.1 brew install kreuzwerker/taps/m1-terraform-provider-helper
  3. Install Terraform
    3.1 brew tap hashicorp/tap
    3.2 brew install hashicorp/tap/terraform
  4. Install the hashicorp/template version v2.2.0
    4.1 m1-terraform-provider-helper install hashicorp/template -v v2.2.0

My terraform version now:

âžś  ~ terraform --version
Terraform v1.1.5
on darwin_arm64

FYI @amaudy

6 Likes

Hi @lpossamai ,
Thanks for the reply.
I followed your steps but couldn’t succeed.
Getting below error after following your steps:

│ Error: Failed to install provider
│ 
│ Error while installing hashicorp/template v2.2.0: the local package for
│ registry.terraform.io/hashicorp/template 2.2.0 doesn't match any of the
│ checksums previously recorded in the dependency lock file (this might be
│ because the available checksums are for packages targeting different
│ platforms)

Do you know the solution to this?

Thanks,

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

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 !!!

11 Likes

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

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

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

This one really worked. Thank you :slight_smile:

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

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.

2 Likes

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.

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

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

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>

1 Like

This worked for me. Thank you!

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

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