go-autorest: Azure go-autorest causing ambiguous import

Got an ambiguous import error when run go get ./… under a go module enabled project:

build github.com/.../cmd/manager: cannot load github.com/Azure/go-autorest/autorest: ambiguous import: found github.com/Azure/go-autorest/autorest in multiple modules:
	github.com/Azure/go-autorest v11.2.8+incompatible (/go/pkg/mod/github.com/!azure/go-autorest@v11.2.8+incompatible/autorest)
	github.com/Azure/go-autorest/autorest v0.3.0 (/go/pkg/mod/github.com/!azure/go-autorest/autorest@v0.3.0)

go-autorest is introduced by client-go. here is the line in my go.mod:

github.com/Azure/go-autorest/autorest v0.3.0 // indirect

but in the go.sum, there are many lines:

github.com/Azure/go-autorest v11.2.8+incompatible h1:Q2feRPMlcfVcqz3pF87PJzkm5lZrL+x6BDtzhODzNJM=
github.com/Azure/go-autorest v11.2.8+incompatible/go.mod h1:r+4oMnoxhatjLLJ6zxSWATqVooLgysK6ZNox3g/xq24=
github.com/Azure/go-autorest/autorest v0.3.0 h1:yOmXNB2qa2Kx40wMZB19YyafzjCHacXPk8u0neqa+M0=
github.com/Azure/go-autorest/autorest v0.3.0/go.mod h1:AKyIcETwSUFxIcs/Wnq/C+kwCtlEYGUVd7FPNb2slmg=
github.com/Azure/go-autorest/autorest/adal v0.1.0 h1:RSw/7EAullliqwkZvgIGDYZWQm1PGKXI8c4aY/87yuU=
github.com/Azure/go-autorest/autorest/adal v0.1.0/go.mod h1:MeS4XhScH55IST095THyTxElntu7WqB7pNbZo8Q5G3E=
github.com/Azure/go-autorest/autorest/date v0.1.0/go.mod h1:plvfp3oPSKwf2DNjlBjWF/7vwR+cUD/ELuzDCXwHUVA=
github.com/Azure/go-autorest/autorest/mocks v0.1.0/go.mod h1:OTyCOPRA2IgIlWxVYxBee2F5Gr4kF2zd2J5cFRaIDN0=
github.com/Azure/go-autorest/logger v0.1.0/go.mod h1:oExouG+K6PryycPJfVSxi/koC6LSNgds39diKLz7Vrc=
github.com/Azure/go-autorest/tracing v0.1.0/go.mod h1:ROEEAFwXycQw7Sn3DXNtEedEvdeRAgDr0izn4z5Ij88=

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Comments: 20 (12 by maintainers)

Commits related to this issue

Most upvoted comments

A replace directive should never be necessary. A more appropriate resolution would be to modify the nested modules to require a version (or pseudo-version) of the parent module that removes the ambiguous package.

(See, for example, the requirement on cloud.google.com/go in https://code-review.googlesource.com/c/gocloud/+/43891.)

For module ./tracing/opencensus I believe the workaround is not required since it wasn’t “carved out” from its parent module (was added later), correct?

That sounds right. You only need the reverse edge to remove ambiguous packages, so if there are no such packages to remove then you’re good without it.

@bcmills you’re right, using replace was bad advice and I admit it stems from still not fully understanding how modules interact with pre-modules dependencies. I’m looking at the reference you provided and read the associated wiki section. To make sure I correctly understand, I’d want to update module ./autorest/validation to have a dependency on its parent module ./autorest, and apply this same logic to all sub-modules. Going forward does that mean that every time a parent module has a minor/patch update all of its sub-modules must be updated to require the new version? Can this “fake” requirement ever be removed (perhaps in v2+)?