Fix module issues once and for all #299

ugorji · 2019-05-23T23:51:51Z

The use of modules in go-codec introduced more headaches than necessary.

It has been a disaster, and I really wish I had waited until the dust settled before making this module aware, especially since so many people depended on this package and it has the atypical "package name differs from directory name" issue.

I regret jumping on modules that early, and having to constantly try to correct my mistakes.

It seems the dust has settled now and we have the tools to:

support the simulation of a multi-module repository

We have 2 options:

Make go/codec its own module using a tag: codec/vX.Y.Z
Keep go as the only module, using a tag: vX.Y.Z
Have both as modules using "same'ish" parallel tags (vX.Y.Z and codec/vX.Y.Z) and corresponding go.mod files

I am not sure if 3. above is supported by go modules. I read that a module doesn't include modules within it.

I will appreciate any thoughts on how best to resolve this. I am including references to places where I have seen folks have issues. I hope that you folks can respond and help me settle this once and for all with the best solution.

https://github.com/golang/go/wiki/Modules#publishing-a-release
https://golang.org/wiki/Modules#faqs--multi-module-repositories

gin-gonic/gin#1897

@dmitshur
@arizvisa
@bvisness
@HZ89
@bcmills
@amarox
@thepudds

trivigy · 2019-05-23T23:59:54Z

@ugorji i am pretty sure that option 3 is a valid solution is probably preferred to support backward compatibility with those folks that depend on the library from the main module.

It is just unfortunate that you will have to maintain two sets of tags requiring making sure that they are always on the same commits.

ugorji · 2019-05-24T02:05:57Z

@trivigy

https://github.com/golang/go/wiki/Modules#faqs--multi-module-repositories

Each module starts at the directory containing its go.mod file, and contains all packages from that directory and its subdirectories recursively, excluding any subtree that contains another go.mod file.

This is why I'm not sure if 3. is a valid option, as this suggest that .../go movie will NOT contain .../go/codec

HZ89 · 2019-05-24T02:53:03Z

I think option 1 is a more practical choice. In gin-gonic, just use go/codec decode msgpack.

dmitshur · 2019-05-24T03:06:26Z

Option 3 will not work easily. If the codec directory contains a go.mod file, its contents are "carved out" from the outer module and won't be included in it. As far as I know, you can only make it work by maintaining two parallel git histories: one for inner module (with go.mod in subdirectory) and another for outer module (without go.mod in subdirectory). I don't think that's practical.

thepudds · 2019-05-24T04:11:40Z

I suspect you could make any of those three options work...

But the simplest in the long-term might be option 2, which is what the remainder of my comment focuses on:

Keep go as the only module, using a tag: vX.Y.Z

Having a single go.mod in the root of a repo is the most common situtation, and it avoids needing to prefix tags and is generally simpler and more widely understood than either of the other two options.

That also happens to be the current state of the latest release here, as far as I've followed -- it seems v1.1.4 has a single go.mod in the repo root: https://github.com/ugorji/go/blob/v1.1.4/go.mod

However, it seems the main issue with the current state is multiple consumers have the old github.com/ugorji/go/codec module path in their go.mod files. One approach to resolving that might be something like adding an FAQ on this repo asking people to upgrade to point to latest of the github.com/ugorji/go module and remove any references to old github.com/ugorji/go/codec module path from their go.mod files. I suspect that might be enough to resolve spf13/viper#658, for example, but I am also not sure until someone actually tries it and sees it work.

In general, moving go.mod files within a repo (which is in effect what happened here) is a very, very tricky situation, but as far as I understand, the best way to handle it is to create a requirement cycle for the moved/added/removed modules within the repo so that any consumer that points to one of the modules automatically gets ratcheted forward to a consistent version of the other module(s) within that same repo.

The modules wiki covers this in a fair amount of detail if you are adding a new module: https://github.com/golang/go/wiki/Modules#is-it-possible-to-add-a-module-to-a-multi-module-repository

However, removing a module from a multi-module repo (which I think is what happened here most recently) is covered much more briefly -- it says:

Is it possible to remove a module from a multi-module repository?
Yes, with the same two cases and similar steps as above.

On the other hand, there is a more precise but older description of removing a module that lives within the code itself. The full section is here, and worth reading:
https://github.com/golang/go/blob/release-branch.go1.12/src/cmd/go/internal/modfetch/repo.go#L106-L125

where this snippet here might be the piece that is most applicable in terms of next steps:

// The gf256 package could move back into the
// original by another simultaneous release of rsc.io/qr v0.4.0 including
// the gf256 subdirectory and an rsc.io/qr/gf256 v0.2.0 with no code
// in its root directory, along with a new requirement cycle.

That might be an approach here -- prepare a new github.com/ugorji/go/codec module that does not have any code in it, set up a requirement cycle between the new github.com/ugorji/go/codec module and a new release of the github.com/ugorji/go module, and then release both. The new github.com/ugorji/go/codec module probably could be on a different branch.

But, I've never done that myself, so take that as a theoretical possibility that might or might not be correct.

Also, there might be a simpler solution.

CC @jadekler (the main author of the multi-module repo documentation)

ugorji · 2019-05-24T05:19:04Z

@thepudds Thanks much for this detailed explanation. Much much appreciated.

I messed things up by not respecting how tricky this would be, and trying to fix it quickly by moving go.mod around, which made it worse. Now there are frustrated users on both the .../go module and .../go/codec module. It will be nice if I could get option 3. to work somehow.

When I read https://github.com/golang/go/blob/release-branch.go1.12/src/cmd/go/internal/modfetch/repo.go#L106-L125 , it suggests to me that I can support both, by having 2 modules that are kept in sync.

github.com/ugorji/go/codec v1.1.5
github.com/ugorji/go v1.1.5 depends on github.com/ugorji/go/codec v1.1.5

This way, folks can use either of the module versions and work.

Do you (or does anyone else with more module experience) see a reason why this wouldn't work?

^^ @jadekler

jeanbza · 2019-05-24T14:56:46Z

I did a light review of the issues involved. It seems like you had added a module below the root, creating a multi-module repository, and then removed it? I agree with @thepudds that the easiest solution is for all your dependors to update to latest version of github.com/ugorji/go and remove the old, non-exsistent github.com/ugorji/go/codec reference.

That might be an approach here -- prepare a new github.com/ugorji/go/codec module that does not have any code in it, set up a requirement cycle between the new github.com/ugorji/go/codec module and a new release of the github.com/ugorji/go module, and then release both. The new github.com/ugorji/go/codec module probably could be on a different branch.

Do you (or does anyone else with more module experience) see a reason why this wouldn't work?

I'm not sure this works: users still would need to upgrade to the later version of the module, no?

Sorry I never got around to fleshing out Is it possible to remove a module from a multi-module repository?. I should go back and add more detail to that.

This commit was created by manually removing github.com/ugorji/go/codec from the go.mod (which now does not exist - see ugorji/go#299) and running `go mod tidy`. This removes the borked github.com/ugorji/go/codec dependency, fixing dependors of this library. This commit should be included in a release ASAP.

jeanbza · 2019-05-24T15:03:59Z

I've created spf13/viper#705 to fix the viper dependency. Any other dependor needs to do the same AFAICT.

This commit was created by manually removing github.com/ugorji/go/codec from the go.mod (which now does not exist - see ugorji/go#299) and running `go mod tidy`. Closes #658

thepudds · 2019-05-24T20:53:59Z

@jadekler thanks for sending that PR to viper! At least so far, that seems to have resolved the problem for viper.

thepudds · 2019-05-24T21:02:39Z

That might be an approach here -- prepare a new github.com/ugorji/go/codec module that does not have any code in it, set up a requirement cycle between the new github.com/ugorji/go/codec module and a new release of the github.com/ugorji/go module, and then release both. The new github.com/ugorji/go/codec module probably could be on a different branch.

I'm not sure this works: users still would need to upgrade to the later version of the module, no?

Hi @jadekler, I think each of the options 1-3 outlined here will involve upgrading.

In the approach I had tried to outline in #299 (comment), the requirement cycle means though that it ends up being a consistent upgrade: you don't end up with a build that has a mix of the old and new (which is what can trigger the ambiguous import error if the same package appears in two modules due to having moved).

thepudds · 2019-05-24T21:32:21Z

@ugorji

Now there are frustrated users on both the .../go module and .../go/codec module. It will be nice if I could get option 3. to work somehow.
...

I think the option I had outlined in #299 (comment) ends up working both for consumers who are currently using the .../go module as well as for consumers currently using the .../go/codec module.

For example, if a consumer is using the .../go/codec module currently, if you were to do the approach in that comment, then when they upgrade, the .../go/codec module ends up not having any code, but it has a require pointing to the .../go module that does have all the code, and that's how they get the right package github.com/ugorji/go/codec (which now no longer triggers an "ambiguous import" error, because that package no longer also lives in the .../go/codec module for those mutually consistent versions of the .../go module and .../go/codec module).

Separately @bcmills looked over that comment and he mentioned he didn't see anything wrong there...

So... I think there's a healthy chance it would work. A concrete next step could be to try on a test repo.

When I read https://github.com/golang/go/blob/release-branch.go1.12/src/cmd/go/internal/modfetch/repo.go#L106-L125 , it suggests to me that I can support both, by having 2 modules that are kept in sync.

github.com/ugorji/go/codec v1.1.5
github.com/ugorji/go v1.1.5 depends on github.com/ugorji/go/codec v1.1.5

I think I am not 100% following the suggestion there, or in particular what you mean by "kept in sync".

If you were to go with that approach, you might need to set up a requirement cycle between the two modules so that they depend on each other, and then also make sure the tagging uses codec/v1.1.5 rather than just v1.1.5 for the github.com/ugorji/go/codec module, etc. But I am not 100% sure.

In any event, I think there are likely multiple workable approaches here, and likely debatable which one is "best".

That said, it seems to me the approach I had outlined in #299 (comment) should work for existing consumers today, and might end up being the simplest over the medium and long term, including you could encourage people via your README to standardize on the .../go module (which is the only module that exists today in v1.1.4, and which viper and gin just started using).

Finally, this is all nuanced enough that whatever approach you are going to try, it probably makes sense to try on a test repo first...

ugorji · 2019-05-25T07:20:40Z

@jadekler wrote

I'm not sure this works: users still would need to upgrade to the later version of the module, no?

Right. They will always need to upgrade to the later version of the module. I just thought that having the module itself be updated might help resolve some of the "ambiguous version" issues. Either way, as @thepudds wrote, an upgrade is needed.

@thepudds wrote

That might be an approach here -- prepare a new github.com/ugorji/go/codec module that does not have any code in it, set up a requirement cycle between the new github.com/ugorji/go/codec module and a new release of the github.com/ugorji/go module, and then release both. The new github.com/ugorji/go/codec module probably could be on a different branch.

I think it would require more churn in the git history if I do it this way, i.e. have a github.com/ugorji/go/codec on a different branch which is empty, and have a requirement cycle between both. Also, that might affect non-module uses (Go 1.9-1.12).

I think the option I had outlined in #299 (comment) ends up working both for consumers who are currently using the .../go module as well as for consumers currently using the .../go/codec module.

For example, if a consumer is using the .../go/codec module currently, if you were to do the approach in that comment, then when they upgrade, the .../go/codec module ends up not having any code, but it has a require pointing to the .../go module that does have all the code, and that's how they get the right package github.com/ugorji/go/codec (which now no longer triggers an "ambiguous import" error, because that package no longer also lives in the .../go/codec module for those mutually consistent versions of the .../go module and .../go/codec module).

My concern here is still the location for it. It feels like a requirements cycle is the main important thing here, that we can enable.

When I read https://github.com/golang/go/blob/release-branch.go1.12/src/cmd/go/internal/modfetch/repo.go#L106-L125 , it suggests to me that I can support both, by having 2 modules that are kept in sync.

github.com/ugorji/go/codec v1.1.5
github.com/ugorji/go v1.1.5 depends on github.com/ugorji/go/codec v1.1.5

I think I am not 100% following the suggestion there, or in particular what you mean by "kept in sync".

If you were to go with that approach, you might need to set up a requirement cycle between the two modules so that they depend on each other, and then also make sure the tagging uses codec/v1.1.5 rather than just v1.1.5 for the github.com/ugorji/go/codec module, etc. But I am not 100% sure.

You are right. I was talking about having 2 tags which point to the same revision (v1.1.5 and codec/v1.1.5) and having go.mod in both folders (.../go and .../go/codec) where they both require one another in a cycle.

That should satisfy your core idea that the 2 "modules" require one another, allowing us to continue to work in master, while supporting module and non-module execution without much churn in github.

Fundamentally, I just want to find out if this will solve some of the issues folks are having so that a go get -u github.com/ugorji/go/codec is sufficient to resolve issues.

erikh · 2019-05-26T23:47:20Z

came here searching for a solution to this, didn't see a message with people running into it so I'll post in the hopes the responses help others.

go get seems to be completely broken with anything depending on msgpack through modules atm. is there any workaround (short of working around go modules in general) that I can implement while ya'll sort this out?

should have clarified originally:

"completely broken" in this case means that I depend on gin-gonic, which depends on msgpack, which depends on go/codec.

[fail:130][118] erikh@tinyci tinyci/ci-gen% GO111MODULE=on go get -u github.com/ugorji/go/codec                                 [16:45]
go: finding github.com/ugorji/go/codec latest
go get: no install location for directory  outside GOPATH
        For more details see: 'go help gopath'

More detail because I wasn't thinking and didn't supply -d the first time:

[fail:1][123] erikh@tinyci tinyci/ci-gen% GO111MODULE=on go get -u -d github.com/ugorji/go/...@master                                                                                                                                                                   [16:52]
go: finding github.com/ugorji/go/codec master
go: finding github.com/ugorji/go master
go get github.com/ugorji/go/...@master: missing github.com/ugorji/go/codec/go.mod at revision 0ecb224b1b75

anyway HTH.

I got it working, but had to downgrade gin to 1.3, for anyone looking.

thepudds · 2019-05-27T00:11:31Z

@erikh would you be able to put together a quick playground link that shows your original problem? You could use this as a starting point:
https://play.golang.org/p/QvLwENa4pTp

erikh · 2019-05-27T00:36:30Z

got a lot on my plate today but I will try to put together a repro tomorrow; sorry, I just deleted about 40k LoC and need to get that into shape. :) I hate seagulls too.

…

On Sun, May 26, 2019 at 5:11 PM thepudds ***@***.***> wrote: @erikh <https://github.com/erikh> would you be able to put together a quick playground link that shows your original problem? You could use this as a starting point: https://play.golang.org/p/QvLwENa4pTp — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#299?email_source=notifications&email_token=AAAET25XEQQRRQXHUN5OJJDPXMRLLA5CNFSM4HPLD7CKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWIQETQ#issuecomment-496042574>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAET24MMR5U5QTDTOGNQ33PXMRLLANCNFSM4HPLD7CA> .

ugorji · 2019-05-27T19:58:41Z

Suppose I create the 2 tags: v1.1.5 and codec/v1.1.5 pointing to the same commit, and go/go.mod and go/codec/go.mod reference each other in a cycle. Will that be sufficient?

I don't know how to generate the error cases, so it's hard for me to test this out. I seemingly have to depend on expert advice and then see what things break.

I keep seeing error reports like: swaggo/gin-swagger#58
Here, they have the v1.1.4 but still see the duplicate from v0....... I am hoping that the cycle will convince go mod not to barf anymore. But I truly am still not sure exactly if that will do it, or how it all works.

thepudds · 2019-05-27T21:08:25Z

That should work.

For testing, one thing you could do is create a branch, then introduce the two modules and tag them with a pair of prerelease tags that do not have the requirement cycle (to see then the error trigger). Then introduce the requirement cycle with a new pair of prelease tags on that branch, which then should avoid the error.

A real consumers would not get any of the prerelease tags by default (only if explicitly asked for, which a real consumer would not normally do).

(On mobile, so brief)

thepudds · 2019-05-27T22:27:54Z

Also, if you do end up putting a branch together like that, I probably can generate a quick example of showing the error triggering, and then showing the error not triggering (as hopefully expected).

ugorji · 2019-05-28T08:36:22Z

@thepudds

https://github.com/ugorji/go/tree/v1.1.5-pre
https://github.com/ugorji/go/tree/test-mod

I created a branch test-mod, added the go/go.mod and go/codec/go.mod, and tagged a version as v1.1.5-pre and tagged it as pre-production in github.

Hope this is sufficient for you.

Thanks.

thepudds · 2019-05-28T10:59:53Z

@ugorji Here is a quick test for you.

It uses github.com/rogpeppe/go-internal/cmd/testscript, which is an extracted version of the internal testscript package that the core Go team heavily uses to test the go command. It provides a shell-like test environment that is nicely tuned to testing how the go command behaves, including asserting which commands should pass, which commands should fail, ability to check stderr/stdout, etc.

If interested, here is an overview of the commands you can place in a testscript here:
https://godoc.org/github.com/rogpeppe/go-internal/testscript

Here is an overview of the testscript utility itself, which provides a convient way to run from the command line:
https://github.com/rogpeppe/go-internal/blob/master/cmd/testscript/README.md

To run the test below, copy it to a file such as go_codec_testscript.txt, then:

$ go get -u github.com/rogpeppe/go-internal/cmd/testscript
$ testscript go_codec_testscript.txt

Here is the basic test I put together just now:

# Test upgrading to new modules github.com/ugorji/go/codec and github.com/ugorji/go works,
# including verifying upgrading to one results in a consistent upgrade to the other 
# due to their cyclic requirements on each other.

# Verify we start in a failing state.
cp go.mod.original go.mod
! go build
stderr 'ambiguous import: found github.com/ugorji/go/codec in multiple modules'

# Getting just github.com/ugorji/[email protected] works,
# and also upgrades us to the other module github.com/ugorji/go/[email protected],
# and does not report any 'ambiguous import' error.
cp go.mod.original go.mod
go get github.com/ugorji/[email protected]
! stderr 'ambiguous import'
go build
! stderr 'ambiguous import'
go list -m all
stdout '^github.com/ugorji/go/codec v1.1.5-pre$'
stdout '^github.com/ugorji/go v1.1.5-pre$'

# Now do the opposite test.
# Getting just github.com/ugorji/go/[email protected] works,
# and also upgrades us to the other module github.com/ugorji/[email protected],
# and does not report any 'ambiguous import' error.
cp go.mod.original go.mod
go get github.com/ugorji/go/[email protected]
! stderr 'ambiguous import'
go build
! stderr 'ambiguous import'
go list -m all
stdout '^github.com/ugorji/go/codec v1.1.5-pre$'
stdout '^github.com/ugorji/go v1.1.5-pre$'

# Updating both github.com/ugorji/go/codec and github.com/ugorji/go at the same time works as well.
cp go.mod.original go.mod
go get github.com/ugorji/go/[email protected] github.com/ugorji/[email protected]
! stderr 'ambiguous import'
go build
! stderr 'ambiguous import'
go list -m all
stdout '^github.com/ugorji/go/codec v1.1.5-pre$'
stdout '^github.com/ugorji/go v1.1.5-pre$'

-- go.mod.original --
module tempmod
require (
        github.com/spf13/viper v1.3.2
        github.com/gin-gonic/gin v1.4.0
)

-- indirectconsumer.go --
package indirectconsumer
import (
	_ "github.com/spf13/viper"
	_ "github.com/gin-gonic/gin"
)

-- go.sum --
github.com/gin-gonic/gin v1.4.0 h1:3tMoCCfM7ppqsR0ptz/wi1impNpT7/9wQtMZ8lr1mCQ=
github.com/gin-gonic/gin v1.4.0/go.mod h1:OW2EZn3DO8Ln9oIKOvM++LBO+5UPHJJDH72/q/3rZdM=
github.com/spf13/viper v1.3.2 h1:VUFqw5KcqRf7i70GOzW7N+Q7+gxVBkSSqiXB12+JQ4M=
github.com/spf13/viper v1.3.2/go.mod h1:ZiWeW+zYFKm7srdB9IoDzzZXaJaI5eL9QjNiN/DMA2s=

Running it reports time taken, along with a 'PASS' result:

$ testscript go_codec_testscript.txt

# Test upgrading to new modules github.com/ugorji/go/codec and github.com/ugorji/go works,
# including verifying upgrading to one results in a consistent upgrade to the other
# due to their cyclic requirements on each other.
# Verify we start in a failing state. (25.274s)
# Getting just github.com/ugorji/[email protected] works,
# and also upgrades us to the other module github.com/ugorji/go/[email protected],
# and does not report any 'ambiguous import' error. (8.778s)
# Now do the opposite test.
# Getting just github.com/ugorji/go/[email protected] works,
# and also upgrades us to the other module github.com/ugorji/[email protected],
# and does not report any 'ambiguous import' error. (1.487s)
# Updating both github.com/ugorji/go/codec and github.com/ugorji/go at the same time works as well. (1.846s)
PASS

thepudds · 2019-05-28T11:03:36Z

Also, running with -v shows the complete output of individual commands, which can be handy if you are interested in modifying or extending that test.

ugorji · 2019-05-28T15:25:00Z

@thepudds Thank you so very much. This is awesome!!!

I just ran it and saw that it passed also.

I will release v1.1.5 by the end of the week with this requirements cycle with a FAQ entry. That should hopefully put these issues to bed, as it should be sufficient to do go get -u github.com/ugorji/go/codec@latest (or alternatively go get -u github.com/ugorji/go@latest).

thepudds · 2019-05-29T21:57:06Z

should be sufficient to do go get -u github.com/ugorji/go/codec@latest

@ugorji Side note: the more interesting test case is probably without the -u.

go get foo (without a -u) updates to the latest version of foo. And go get foo is equivalent to go get foo@latest — in other words, @latest is the default if no @ version is specified.

The -u in go get -u foo or go get -u foo@latest means to also get the latest versions for all of the direct and indirect dependencies of foo.

I could be wrong about this, but in your case I think in theory that means the cyclical requirements could have the incorrect (too old) versions listed, and go get github.com/ugorji/go/codec@latest would fail but go get -u github.com/ugorji/go/codec@latest would work (because the other module would be upgraded to the semantically highest version because of the -u).

In any event, I suspect a test without using -u is a stronger test, but if you want you could test both with and without the -u. The test I sent above did not use the -u given I was thinking that is the stronger test, but part of what is nice about a written testscript is that it is relatively straightforward to extend to cover a few more cases.

ugorji · 2019-05-29T22:04:40Z

@thepudds

should be sufficient to do go get -u github.com/ugorji/go/codec@latest

@ugorji Side note: the more interesting test case is probably without the -u.

I just ran with -u and without -u, and the tests still pass.

I could be wrong about this, but in your case I think in theory that means the cyclical requirements could have the incorrect (too old) versions listed, and go get github.com/ugorji/go/codec@latest would fail but go get -u github.com/ugorji/go/codec@latest would work (because the other module would be upgraded to the semantically highest version because of the -u).

In any event, I suspect a test without using -u is a stronger test, but if you want you could test both with and without the -u. The test I sent above did not use the -u given I was thinking that is the stronger test, but part of what is nice about a written testscript is that it is relatively straightforward to extend to cover a few more cases.
I'm not knowledgeable enough about modules to know whether I am testing all the variations, but that is good news.

I will test with both when I push 1.1.5 (likely over the weekend).

thepudds · 2019-05-29T22:08:42Z

Great.

(If the versions are set properly in the cyclical requirements, I would expect both with and without -u to pass. Just wanted to share a potential concern that the -u version might pass in a test and not catch that the versions were set improperly).

ugorji · 2019-06-02T19:23:47Z

FYI - I am moving the update to upcoming weekend. I wanted to get a few enhancement requests that came in over the past week in, and then give a week to soak before cutting a new release.

marcoippolito · 2019-06-10T15:45:23Z

I'm having the same problem as described here: #303

Please let me know how to solve it

qaisjp · 2019-06-10T15:51:14Z

I'm having the same problem as described here: #303

Please let me know how to solve it

Add this line to your go.mod:

replace github.com/ugorji/go v1.1.4 => github.com/ugorji/go/codec v0.0.0-20190204201341-e444a5086c43

marcoippolito · 2019-06-10T18:37:43Z

@qaisjp thanks for your hint. There must be something else to fix:

Even if actually modified go.mod:

marco@pc01:~/go/src/github.com/gin-gonic/gin$ nano go.mod  

module github.com/gin-gonic/gin

go 1.12

require (
        github.com/gin-contrib/sse v0.1.0
        github.com/golang/protobuf v1.3.1
        github.com/json-iterator/go v1.1.6
        github.com/mattn/go-isatty v0.0.7
        github.com/modern-go/concurrent v0.0.0-20180306012644-bacd9c7ef1dd // indirect
        github.com/modern-go/reflect2 v1.0.1 // indirect
        github.com/stretchr/testify v1.3.0
        github.com/ugorji/go v1.1.4
        golang.org/x/net v0.0.0-20190503192946-f4e77d36d62c
        gopkg.in/go-playground/assert.v1 v1.2.1 // indirect
        gopkg.in/go-playground/validator.v8 v8.18.2
        gopkg.in/yaml.v2 v2.2.2
)

The problem persists:

marco@pc01:~/go/marcoGolang/gin-examples/multiple-service$ go run main.go 
go: finding github.com/golang/protobuf v1.3.1
go: finding github.com/dustin/go-broadcast v0.0.0-20171205050544-f664265f5a66
go: finding github.com/manucorporat/stats v0.0.0-20180402194714-3ba42d56d227
go: finding github.com/jessevdk/go-assets v0.0.0-20160921144138-4f4301a06e15
go: finding github.com/thinkerou/favicon v0.1.0
go: finding github.com/stretchr/testify v1.3.0
go: finding github.com/newrelic/go-agent v2.7.0+incompatible
go: finding github.com/gin-gonic/gin v1.4.0
go: finding github.com/gin-gonic/autotls v0.0.0-20190406003154-fb31fc47f521
go: finding github.com/golang/protobuf v1.2.0
go: finding github.com/davecgh/go-spew v1.1.0
go: finding github.com/pmezard/go-difflib v1.0.0
go: finding github.com/modern-go/reflect2 v1.0.1
go: finding github.com/ugorji/go v1.1.4
go: finding github.com/stretchr/objx v0.1.0
go: finding github.com/gin-contrib/sse v0.0.0-20170109093832-22d885f9ecc7
go: finding github.com/json-iterator/go v1.1.5
go: finding github.com/gin-gonic/gin v1.3.0
go: finding github.com/mattn/go-isatty v0.0.4
go: finding github.com/mattn/go-isatty v0.0.7
go: finding github.com/gin-contrib/sse v0.0.0-20190301062529-5545eab6dad3
go: finding github.com/modern-go/concurrent v0.0.0-20180306012644-bacd9c7ef1dd
go: finding github.com/ugorji/go/codec v0.0.0-20181209151446-772ced7fd4c2
go: finding github.com/json-iterator/go v1.1.6
build command-line-arguments: cannot load github.com/ugorji/go/codec: ambiguous import: found     
github.com/ugorji/go/codec in multiple modules:
    github.com/ugorji/go v1.1.4 (/home/marco/go/pkg/mod/github.com/ugorji/[email protected]/codec)
    github.com/ugorji/go/codec v0.0.0-20181209151446-772ced7fd4c2 (/home/marco/go/pkg
/mod/github.com/ugorji/go/[email protected])
marco@pc01:~/go/marcoGolang/gin-examples/multiple-service$

I found that a new directory within go/pkg/mod/cache/download/github.com is created:

marco@pc01:~/go/pkg/mod/cache/download/github.com/ugorji$ ls -lah
total 12K
drwxrwxr-x  3 marco marco 4.0K Jun 10 18:46 .
drwxrwxr-x 17 marco marco 4.0K Jun 10 18:46 ..
drwxrwxr-x  4 marco marco 4.0K Jun 10 18:46 go

marco@pc01:~/go/pkg/mod/cache/download/github.com/ugorji/go/@v$ ls -lah
total 20K
drwxrwxr-x 2 marco marco 4.0K Jun 10 18:53 .
drwxrwxr-x 4 marco marco 4.0K Jun 10 18:46 ..
-rw------- 1 marco marco    7 Jun 10 18:46 list
-rw-rw-r-- 1 marco marco    0 Jun 10 18:46 list.lock
-rw------- 1 marco marco   50 Jun 10 18:46 v1.1.4.info
-rw------- 1 marco marco   29 Jun 10 18:46 v1.1.4.mod

marco@pc01:~/go/pkg/mod/cache/download/github.com/ugorji/go/codec/@v$ ls -lah
total 20K
drwxrwxr-x 2 marco marco 4.0K Jun 10 18:46 .
drwxrwxr-x 3 marco marco 4.0K Jun 10 18:46 ..
-rw------- 1 marco marco   35 Jun 10 18:46 list
-rw-rw-r-- 1 marco marco    0 Jun 10 18:46 list.lock
-rw------- 1 marco marco   78 Jun 10 18:46 v0.0.0-20181209151446-772ced7fd4c2.info
-rw------- 1 marco marco   35 Jun 10 18:46 v0.0.0-20181209151446-772ced7fd4c2.mod


marco@pc01:~/go/pkg/mod/cache/download/github.com/ugorji/go/codec/@v$ cat list
v0.0.0-20181209151446-772ced7fd4c2

ugorji · 2019-06-12T17:31:10Z

@marcoippolito I will be pushing out a v1.2 release around the end of next week. Just FYI, in case that helps.

ugorji · 2019-07-02T15:09:33Z

I just released a go-codec production release - version 1.1.7 (finally) with the fixes to ensure the import paths github.com/ugorji/go and github.com/ugorji/go/codec both work seamlessly.

Please let me know if seeing any issues. If all is well over the next few days, I will close this github issue.

See

https://github.com/ugorji/go/releases/latest
https://github.com/ugorji/go/releases/tag/v1.1.7

ugorji · 2019-07-22T12:42:06Z

Closing now after 3 weeks with no issues raised.

Thanks for all your help, folks!

ugorji/go#299 ugorji/go#318 ugorji/go#319

ugorji added the Urgent label May 23, 2019

anthonyfok mentioned this issue May 24, 2019

Fix codecgen version mismatch spf13/viper#672

Closed

jeanbza mentioned this issue May 24, 2019

clean up dependencies (particularly github.com/ugorji/go/codec) spf13/viper#705

Merged

dcarbone mentioned this issue May 24, 2019

MsgpackHandle.RawToString in composite literal no longer works #290

Closed

thepudds mentioned this issue May 24, 2019

cmd/go: can't use "replace" directive on Windows golang/go#32215

Closed

bep pushed a commit to spf13/viper that referenced this issue May 24, 2019

Clean up dependencies

b5bf975

This commit was created by manually removing github.com/ugorji/go/codec from the go.mod (which now does not exist - see ugorji/go#299) and running `go mod tidy`. Closes #658

ugorji mentioned this issue Jun 12, 2019

cannot load github.com/ugorji/go/codec: ambiguous import: found github.com/ugorji/go/codec in multiple modules #303

Closed

ugorji closed this as completed Jul 22, 2019

bcmills mentioned this issue Aug 8, 2019

cmd/go: ambiguous error message on ambiguous import golang/go#32128

Open

ugorji mentioned this issue Sep 16, 2019

Go Mod Issue #318

Closed

rhcarvalho mentioned this issue Dec 5, 2019

Dependencies conflict while updates the sentry version to 0.3.1 getsentry/sentry-go#87

Closed

mrhwick pushed a commit to DataDog/viper that referenced this issue Feb 27, 2020

Try fixing go.mod problem from ugorji/go/codec

2922e44

ugorji/go#299 ugorji/go#318 ugorji/go#319

xshyne88 mentioned this issue Mar 9, 2020

Drop dependency on subpackage ably/ably-go#123

Closed

mattheworiordan mentioned this issue Mar 9, 2020

Drop dependency on subpackage ably/ably-go#134

Closed

ugorji mentioned this issue Sep 11, 2020

Remove circular dependency on codec submodule #319

Closed

vbatts mentioned this issue Jul 12, 2021

Add go.mod and pin dependencies opencontainers/image-spec#810

Closed

ugorji mentioned this issue Dec 17, 2022

missing go.sum entry needed to verify package #381

Closed

fredmaggiowski mentioned this issue Oct 17, 2023

fix: go mod ambiguous imports rond-authz/rond#277

Merged

Wayc0des-Land mentioned this issue Nov 20, 2024

[Teamserver-Client--Bug]: module github.com/ugorji/go: not a known dependency HavocFramework/Havoc#516

Open

1 task

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix module issues once and for all #299

Fix module issues once and for all #299

ugorji commented May 23, 2019

trivigy commented May 23, 2019 •

edited

Loading

ugorji commented May 24, 2019

HZ89 commented May 24, 2019

dmitshur commented May 24, 2019

thepudds commented May 24, 2019

ugorji commented May 24, 2019

jeanbza commented May 24, 2019 •

edited

Loading

jeanbza commented May 24, 2019

thepudds commented May 24, 2019

thepudds commented May 24, 2019 •

edited

Loading

thepudds commented May 24, 2019 •

edited

Loading

ugorji commented May 25, 2019

erikh commented May 26, 2019 •

edited

Loading

thepudds commented May 27, 2019

erikh commented May 27, 2019 via email

ugorji commented May 27, 2019

thepudds commented May 27, 2019

thepudds commented May 27, 2019

ugorji commented May 28, 2019 •

edited

Loading

thepudds commented May 28, 2019

thepudds commented May 28, 2019

ugorji commented May 28, 2019

thepudds commented May 29, 2019

ugorji commented May 29, 2019

thepudds commented May 29, 2019

ugorji commented Jun 2, 2019

marcoippolito commented Jun 10, 2019

qaisjp commented Jun 10, 2019

marcoippolito commented Jun 10, 2019 •

edited

Loading

ugorji commented Jun 12, 2019

ugorji commented Jul 2, 2019

ugorji commented Jul 22, 2019

Fix module issues once and for all #299

Fix module issues once and for all #299

Comments

ugorji commented May 23, 2019

trivigy commented May 23, 2019 • edited Loading

ugorji commented May 24, 2019

HZ89 commented May 24, 2019

dmitshur commented May 24, 2019

thepudds commented May 24, 2019

ugorji commented May 24, 2019

jeanbza commented May 24, 2019 • edited Loading

jeanbza commented May 24, 2019

thepudds commented May 24, 2019

thepudds commented May 24, 2019 • edited Loading

thepudds commented May 24, 2019 • edited Loading

ugorji commented May 25, 2019

erikh commented May 26, 2019 • edited Loading

thepudds commented May 27, 2019

erikh commented May 27, 2019 via email

ugorji commented May 27, 2019

thepudds commented May 27, 2019

thepudds commented May 27, 2019

ugorji commented May 28, 2019 • edited Loading

thepudds commented May 28, 2019

thepudds commented May 28, 2019

ugorji commented May 28, 2019

thepudds commented May 29, 2019

ugorji commented May 29, 2019

thepudds commented May 29, 2019

ugorji commented Jun 2, 2019

marcoippolito commented Jun 10, 2019

qaisjp commented Jun 10, 2019

marcoippolito commented Jun 10, 2019 • edited Loading

ugorji commented Jun 12, 2019

ugorji commented Jul 2, 2019

ugorji commented Jul 22, 2019

trivigy commented May 23, 2019 •

edited

Loading

jeanbza commented May 24, 2019 •

edited

Loading

thepudds commented May 24, 2019 •

edited

Loading

thepudds commented May 24, 2019 •

edited

Loading

erikh commented May 26, 2019 •

edited

Loading

ugorji commented May 28, 2019 •

edited

Loading

marcoippolito commented Jun 10, 2019 •

edited

Loading