Is it possible for you to share an example repo that duplicates this? I'm not sure how it pulled one dep from a module and another dep from a vendor folder.

Not trivially, no, this is in a private repo.

Repository A vendors repository B. Both repository A and B have github.com/aws/aws-sdk-go vendored. Running go mod -init in repository A worked fine, but compilation failed with the above.

I should also mention that vendoring is currently managed with dep.

In module mode, the go command intentionally ignores /vendor directories.

Repository A vendors repository B. Both repository A and B have github.com/aws/aws-sdk-go vendored.

Which vendored copy do you expect the build to use?

If both A and B vendor the same pristine copy of github.com/aws/aws-sdk-go, then you should be able to go get github.com/aws/aws-sdk-go@$VERSION in both modules and have everything work as expected, independent of the /vendor directory.

On the other hand, if the vendored copy has changes that are intentionally not compatible with a tagged release of aws-sdk-go, then either it should have a distinct import path (e.g. github.com/alecthomas/aws-sdk-go) or a replace directive (replace github.com/aws/aws-sdk-go => github.com/alecthomas/aws-sdk-go v1.15.0) in both modules.

I should also mention that vendoring is currently managed with dep.

If the vendored copy of aws-sdk-go is a pristine upstream version specified in your Gopkg.lock file, does go mod -init correctly add a require directive for that version?

Which vendored copy do to expect the build to use?

It's the same pristine version, so I don't care which one it uses.

If both A and B vendor the same pristine copy of github.com/aws/aws-sdk-go, then you should be able to go get github.com/aws/aws-sdk-go@$VERSION in both modules and have everything work as expected, independent of the /vendor directory.

Only one of the two repositories has been "go modularised", repository A.

One question, should I be able to delete the vendor directory at this stage of development, or is that still a work in progress?

If you don't need reproducible builds without module support, you should be able to delete the vendor directory. (In module mode, you should be able to build without it.)

That's a pretty big “if”, but it's your repo. 🙂

The report is a bit hard to follow since it is so abstract, but this error looks wrong to me:

```
cmd/internal/auth/auth.go:35:42: cannot use creds (type 
*"importedproject/vendor/github.com/aws/aws-sdk-go/aws/credentials".Credentials) as type 
*"github.com/aws/aws-sdk-go/aws/credentials".Credentials in argument to connectors.NewAWSConnector
```

When using go modules, vendor directories should be ignored entirely. It should not be possible to end up with a package "importedproject/vendor/github.com/aws/aws-sdk-go/aws/credentals" in the build at all. It sounds like "importedproject/somethig" imports "github.com/aws/aws-sdk-go/aws/credentials" and that resolved to the vendored copy instead of the real one chosen for the overall build. If so, that's a mistake. We just need to isolate the test case showing why it happens.

A little more information would help. Can you post your go.mod (with "importedproject" or whatever is fine)? Can you tell if importedproject imports "github.com/aws/aws-sdk-go/aws/credentials"? Does it import it using that exact path? Or maybe does it import it using "importedproject/vendor/github.com/aws/aws-sdk-go/aws/credentals? (That should be impossible but we've already established there's a bug somewhere.)

Thanks.

I've replicated this in some minimal public repositories:

$ go-tip get github.com/alecthomas/test0
$ cd $GOPATH/src/github.com/alecthomas/test0
$ go-tip install ./...
$ go-tip mod -init
go: creating new go.mod: module github.com/alecthomas/test0
go: copying requirements from Gopkg.lock
$ go-tip install ./...
$ rm -rf vendor
$ go-tip install ./...
main.go:6:2: cannot find package "github.com/alecthomas/test1" in any of:
	/Users/aat/bin/go.tip/src/github.com/alecthomas/test1 (from $GOROOT)
	/Users/aat/.go/src/github.com/alecthomas/test1 (from $GOPATH)
$ go-tip get ./...
# github.com/alecthomas/test0
./main.go:12:7: cannot use arn1 (type "github.com/alecthomas/test1/vendor/github.com/aws/aws-sdk-go/aws/arn".ARN) as type "github.com/aws/aws-sdk-go/aws/arn".ARN in assignment
./main.go:13:7: cannot use arn0 (type "github.com/aws/aws-sdk-go/aws/arn".ARN) as type "github.com/alecthomas/test1/vendor/github.com/aws/aws-sdk-go/aws/arn".ARN in assignment

Apologies for not having a replicable example before.

As I mentioned initially, I'm not sure this specific combination of actions is expected to work at all, or is even reasonable to expect to work.

It is expected to work with GO111MODULE=on, but since the code is in $GOPATH/src, it should fall back to a non-module build (i.e., using /vendor) in auto mode.

Aha! Setting GO111MODULE=on does indeed work. Sorry for the noise :(

I'm really sorry but the problem here is that modules are not enabled for your commands. I will take this as a sign that we need to make the non-module usage inside GOPATH/src clearer. Maybe even a warning print, as much as I hate those. Perhaps go mod -init should have failed too.

$ export GOPATH=/tmp/gp1
$ go get github.com/alecthomas/test0
$ cd $GOPATH/src/github.com/alecthomas/test0
$ go install ./...
$ go mod -init
go: creating new go.mod: module github.com/alecthomas/test0
go: copying requirements from Gopkg.lock
$ go install ./...
$ rm -rf vendor
$ go install ./...
main.go:6:2: cannot find package "github.com/alecthomas/test1" in any of:
	/Users/rsc/go/src/github.com/alecthomas/test1 (from $GOROOT)
	/tmp/gp1/src/github.com/alecthomas/test1 (from $GOPATH)
main.go:4:2: cannot find package "github.com/aws/aws-sdk-go/aws/arn" in any of:
	/Users/rsc/go/src/github.com/aws/aws-sdk-go/aws/arn (from $GOROOT)
	/tmp/gp1/src/github.com/aws/aws-sdk-go/aws/arn (from $GOPATH)
$ GO111MODULE=on go install ./...
go: finding github.com/aws/aws-sdk-go v1.14.27
go: finding github.com/alecthomas/test1 v0.0.0-20180717001517-0b8cedefc96b
go: downloading github.com/aws/aws-sdk-go v1.14.27
go: downloading github.com/alecthomas/test1 v0.0.0-20180717001517-0b8cedefc96b
$ 

Ah, of course. That makes complete sense now.