When v1.0.0 is tagged on the SDK repo, bump version used in defaultSDKVersion in migrate.go and sdkVersionConstraint in check.go.

This is what happens when I try to re-run migrate on already migrated provider:

tf-sdk-migrator migrate --sdk-version=master

Checking Go runtime version ...
Go version 1.12.9: OK.
Checking whether provider uses Go modules...
Go modules in use: OK.
Checking version of github.com/hashicorp/terraform SDK used in provider...
SDK version could not be determined. Provider must use hashicorp/terraform SDK.
[WARN] Error getting SDK version for provider /Users/radeksimko/gopath/src/github.com/terraform-providers/terraform-provider-dns: 2 errors occurred:
	* require statement with path "github.com/hashicorp/terraform" not found
	* could not read SDK version from go.mod file for provider/Users/radeksimko/gopath/src/github.com/terraform-providers/terraform-provider-dns


Provider failed eligibility check for migration to the new SDK. Please see warnings above.

As a user I would expect the migrator to check:

1. If there's already github.com/hashicorp/terraform-plugin-sdk >= 1.0 in go.mod, then just print success/info message Provider already migrated
2. If there isn't terraform-plugin-sdk, print error message %s [path] doesn't look like a path to Terraform provider as it doesn't import github.com/hashicorp/terraform

Instead of hardcoding as in #42.

A whitelist of allowed SDK packages is more maintainable than a blacklist.

While I appreciate the aim of keeping the implementation simple, I'm afraid we may miss some important implementation details of go list when we launch this tool into the wild.

e.g. testdata directories are generally not meant to be imported (and so we shouldn't parse them when scanning for all eligible *.go files to find imports in), packages may be imported under different names, which go-refs doesn't handle etc. Who knows what other weird edge cases we may bump into...

I'm aware that calling out to go via shell comes at the cost of increased complexity, but I think the cost is ok, if we get better accuracy?

Just food for thought 🥘 💭

I would make the sdk version an arg/flag so it can be forced to a particular version or master which is convenient in testing.

$ tf-sdk-migrator migrate -to master

This was a last minute change last week I believe. I think we came to a consensus to not prefix with sdk.

Checking the Go version for eligibility has one major purpose: ensuring modules are resolved correctly when running tf-sdk-migrator migrate, which we believe will happen with a Go version of >=1.12.

The tf-sdk-migrator check currently reads the Go version from .go-version, go.mod, and .travis.yml, which is a poor proxy for the version of Go that will be used to perform the actual migration.

We can just call go version during the eligibility check instead.

Proposed name: v2upgrade

This will need to:

• Check for deprecations that cannot be automatically migrated

• Search and replace terraform.ResourceProvider type -> *schema.Provider type

• Search and replace validation functions in hashicorp/terraform-plugin-sdk#333

This may not be needed, but I'm removing the TODO in migrate.go.

Hello,
Thanks for this great tool that you are giving us.
I've been struggling with this deprecation notice : after running
tf-sdk-migrator check github.com/Telmate/terraform-provider-proxmox

Checking Go runtime version ...
Go version 1.14.6: OK.
Checking whether provider uses Go modules...
Go modules in use: OK.
Checking version of github.com/hashicorp/terraform-plugin-sdk to determine if provider was already migrated...
Checking version of github.com/hashicorp/terraform used in provider...
Terraform version 0.12.10: OK.
Checking whether provider uses deprecated SDK packages or identifiers...
Deprecated SDK packages in use:
 * github.com/hashicorp/terraform/communicator/remote
 * github.com/hashicorp/terraform/communicator

Some constraints not satisfied. Please resolve these before migrating to the new SDK.

I have search for this in the git repo but not found any clues. And the communicator package seems OK

Please help me understand why 👍

It is not my provider I'm just trying to migrate from legacy sdk.

While attempting the V2 upgrade, I ran tf-sdk-migrator v2upgrade and hit some issues to fix. As the output wasn't entirely clear, I ran it again after fixing the issues resulting in paths that duplicated the v2/ portion of the module name.

--- cloudflare/data_source_zone_dnssec.go
+++ cloudflare/data_source_zone_dnssec.go
@@ -6,7 +6,7 @@ import (
        "log"

        "github.com/cloudflare/cloudflare-go"
-       "github.com/hashicorp/terraform-plugin-sdk/helper/schema"
+       "github.com/hashicorp/terraform-plugin-sdk/v2/v2/helper/schema"
 )

This wasn't too problematic to fix however it was unexpected and thought I'd document the issue for others.

The usage path I followed probably wasn't correct however perhaps a warning that the v2/ rewrite had already happened and either halt or skip would be useful?

Most if not all providers are still vendoring dependencies. I don't think the migrator should necessarily run go mod vendor for them. I think it should run go mod tidy after the migration, mention that it did, and then mention

If you are vendoring dependencies, remember to run go mod vendor

Or something along those lines.

The aws provider is a rare provider with no .go-version, no go version in the go.mod file, and a travis file with an unexpected format:

Checking Go version used in provider...
2019/08/27 19:22:40 no Go version found in .go-version file for /Users/alex/git/go/src/github.com/terraform-providers/terraform-provider-aws: open /Users/alex/git/go/src/github.com/terraform-providers/terraform-provider-aws/.go-version: no such file or directory
2019/08/27 19:22:40 no go version found in go.mod file for /Users/alex/git/go/src/github.com/terraform-providers/terraform-provider-aws: go statement not found
2019/08/27 19:22:40 no go version found in Travis config file for /Users/alex/git/go/src/github.com/terraform-providers/terraform-provider-aws: Malformed version: include:
2019/08/27 19:22:40 failed to detect Go version for provider /Users/alex/git/go/src/github.com/terraform-providers/terraform-provider-aws
Go version does not satisfy constraint >=1.12. Found Go version: .

I had some questions/suggestions
Should we make only the use of go modules and currently being on v0.12 of TF a requirement, and the others just warnings? Are deprecated identifiers a blocker? Could we have the migrator skip rewriting the imports of the affect files and allow the import to exist. I can't recall the rationale for requiring go1.12, would being on modules not be enough? Certainly being on 1.12+ is a nice to have.

EDIT:
It appears only the deprecated identifiers is a blocker, you can likely close this issue, you may want to see the AWS providers travis file to see if can still be parsed, in general though the go version seems low priority/concern