go.mod placement introduces an ambiguous import error #279
Comments
|
As a workaround in the interim, anyone running into the ambiguous import error can apply the fix themselves by running |
|
why v1.1.2-XXX ? I am a big confused, and I don't want to make assumptions. |
I don't understand why this works? There's no tag v1.1.2. Is this a git thing, and if so, can you explain? I truly don't understand the quirks of modules yet. I just want to support a multi-module repo, which is what I had been wanting from the beginning, and this feels like the best time to get it setup. I want folks to treat github.com/ugorji/go/codec as a module in itself (not github.com/ugorji/go) |
This should workaround the ambiguous import errors using modules. It requires that we tag a new release right after this change (as v1.1.2) Hope it works Updates #279
|
This should be fixed now, as at 8fd0f8d . Please let me know if this is fixed for you. |
|
Thanks for the fix!
That's the pseudo-version at which the packages were removed from the root module, so that requirement ensures that only the |
…#2057) Updates #2048 - moves the go.mod file from samples/appengine to samples. Note the replace gocloud.dev => ../ added to the go.mod. Without this, running go test ./... in samples/ results in many errors like: can't load package: package gocloud.dev/samples/server: unknown import path "gocloud.dev/samples/server": ambiguous import: found gocloud.dev/samples/server in multiple modules: gocloud.dev/samples (/home/eliben/eli/go-cloud/samples/server) gocloud.dev v0.13.0 (/home/eliben/eli/go/pkg/mod/[email protected]/samples/server) The symptom and solution is explained by bcmills in ugorji/go#279 (which refers also to golang/go#27899). The new go.mod points to gocloud.dev v0.13, which also provides these packages - so the go command is confused - it sees the same package(s) provided by two different modules. The ugorji/go solution was to use a pseudo-version pointing at an existing commit in the core module which removes the packages - this removes the ambiguity. In our case, there is no existing commit yet - so I'm using a replace line. The replace line should be unnecessary when we release a new CDK version. This has interesting implications for #886 - we'll likely have to do the same when we split out providers to their own modules and retain replace lines until a new release.
|
Hi folks, Please see #299 and add your thoughts/ideas/etc. Thanks. |
|
FYI: I just released a go-codec production release - version 1.1.7 (finally) First, it resolves the go.mod impasse where we had different import paths (github.com/ugorji/go and github.com/ugorji/go/codec) causing the ambiguous import error. This is now fixed by leveraging import cycles to ensure that either one works well and resolves to the same bits. Please let me know if seeing any issues. If all is well over the next few days, I will close this github issue. |
- Fix invalid pseudo-version - Pull in k8s.io bugfix - Add github.com/ugoriji/go v1.17 to address ambiguous import error [1] [1] ugorji/go#279 (comment)
The
go.modfile introduced for #259 effectively splits theugorji/gorepository into two separate modules:github.com/ugorji/goandgithub.aaakk.us.kg/ugorji/go/codec.A repository without a
go.modfile is effectively a single module, so prior to the introduction of that file, the latest tagged version (v1.1.1) had all of the packages in modulegithub.aaakk.us.kg/ugorji/go, and some existing users already depended on that module (https://github.com/etcd-io/etcd/blob/329be66e8b3f9e2e6af83c123ff89297e49ebd15/go.mod#L45).Now, if some program combines those existing users with a user of the new module, they receive two distinct copies of each package (via the two distinct modules), and the build fails with an
ambiguous importerror:To resolve this problem, I recommend that you add the following line to
github.com/ugorji/go/codec/go.mod:Until golang/go#27899 is resolved, you may need to re-add the line whenever you run
go mod tidy, or add another.gosource file to ensure that it is not removed (as described in golang/go#27899 (comment)).The text was updated successfully, but these errors were encountered: