go module uses invalid version

[jaloren]

I am on go 1.13. If I do go get in module mode, I get the following error

go get github.com/terraform-providers/terraform-provider-template@v2.1.2
go: finding github.com/terraform-providers/terraform-provider-template v2.1.2
go get github.com/terraform-providers/terraform-provider-template@v2.1.2: github.com/terraform-providers/terraform-provider-template@v2.1.2: invalid version: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v2

I believe the issue is that go.mod exists on a tagged git version higher on a high major semver version than 1. To fix this problem, the module path needs a /v2 at the end

module github.com/terraform-providers/terraform-provider-template

See here for details:

https://github.com/golang/go/wiki/Modules#semantic-import-versioning

[apparentlymart]

Hi @jaloren!

Although this codebase contains Go code in a main module, it is not intended as a Go library. The semantic versioning on this repository applies to the API of this provider as seen by Terraform. This codebase produces an executable program terraform-provider-template, not a Go library.

If you were retrieving the code from this provider in order to build it into an executable to use with Terraform, please follow the instructions in the readme instead, cloning the repository with git clone rather than using go get.

If you are intending to make use of the functionality in this codebase from some other program than Terraform, you'll need to instead launch it as a Terraform plugin process and call into it that way. There is not currently any supported way to do that; Terraform itself is the only plugin client we maintain.

I have a personal project (not an official HashiCorp project) for an experimental library for launching and consuming Terraform providers. It is not feature complete, but it hopefully serves as an example of how a separate program can call into Terraform providers via the grpc plugin protocol.

[jaloren]

Hi @apparentlymart,

I encountered this issue while trying to go build the aws terraform provider. That provider is trying to use terraform-provider-template library.

https://github.com/terraform-providers/terraform-provider-aws/blob/master/go.mod#L23

And that in turn is causing the build to fail. So does this mean the provider should not be including the template library as requirement in their go.mod?

Out of curiosity, what's the reason for the module to not conform to semantic import versioning?

[apparentlymart]

Hi @jaloren,

Indeed, the AWS provider is moving to remove these dependencies right now. Before when it was technically possible to use providers as libraries some of them were used in that way even though that wasn't the intent (hundreds of people have contributed to the major providers over the years), so it'll take some work to undo that. You can see that work in progress in terraform-providers/terraform-provider-aws#10021, and some other PRs. Once that is complete, the AWS provider will not depend on any other provider codebases as libraries.

Note that all of the Terraform codebases are currently still built using Go 1.12, since we've not yet completed the work to prepare for switching to Go 1.13. If you plan to contribute to Terraform Core or any of the providers then best to stick with Go 1.12 for now, since that's what the development process tooling is assuming. With that said, you may be able to use Go 1.13 if you build in vendor mode (go install -mod=vendor), since all of the dependencies are already present in the repository and that is how official Terraform and provider releases are prepared anyway.

As I was describing before, the tags on the provider repositories are for provider releases, not Go library releases. The major version of a provider increments when there is a breaking change to the provider as a Terraform configuration would use it, not when there is a breaking change to the Go packages that the provider is built from. It would be misleading to imply that we're following semantic Go-style import versioning when in practice breaking changes to the Go packages are possible at any time, even in a minor release. Semantic import versioning only applies to modules that are to be imported by other modules, but the providers are roots in the dependency graph and nothing else should depend on them.

[jaloren]

Thank you for the explanation.