Fix module issues once and for all
ugorji opened this issue · 32 comments
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
@dmitshur
@arizvisa
@bvisness
@HZ89
@bcmills
@amarox
@thepudds
@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.
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
I think option 1 is a more practical choice. In gin-gonic, just use go/codec decode msgpack.
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.
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)
@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
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.
I've created spf13/viper#705 to fix the viper dependency. Any other dependor needs to do the same AFAICT.
@jadekler thanks for sending that PR to viper! At least so far, that seems to have resolved the problem for viper.
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).
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...
@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/codecmodule that does not have any code in it, set up a requirement cycle between the newgithub.com/ugorji/go/codecmodule and a new release of thegithub.com/ugorji/gomodule, and then release both. The newgithub.com/ugorji/go/codecmodule 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.5I 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.
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.
@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
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.
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)
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).
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.
@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/go@v1.1.5-pre works,
# and also upgrades us to the other module github.com/ugorji/go/codec@v1.1.5-pre,
# and does not report any 'ambiguous import' error.
cp go.mod.original go.mod
go get github.com/ugorji/go@v1.1.5-pre
! 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/codec@v1.1.5-pre works,
# and also upgrades us to the other module github.com/ugorji/go@v1.1.5-pre,
# and does not report any 'ambiguous import' error.
cp go.mod.original go.mod
go get github.com/ugorji/go/codec@v1.1.5-pre
! 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/codec@v1.1.5-pre github.com/ugorji/go@v1.1.5-pre
! 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/go@v1.1.5-pre works,
# and also upgrades us to the other module github.com/ugorji/go/codec@v1.1.5-pre,
# and does not report any 'ambiguous import' error. (8.778s)
# Now do the opposite test.
# Getting just github.com/ugorji/go/codec@v1.1.5-pre works,
# and also upgrades us to the other module github.com/ugorji/go@v1.1.5-pre,
# 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
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.
@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).
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.
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@latestwould fail butgo get -u github.com/ugorji/go/codec@latestwould 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
-uis 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-ugiven 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).
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).
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.
I'm having the same problem as described here: #303
Please let me know how to solve it
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
@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/go@v1.1.4/codec)
github.com/ugorji/go/codec v0.0.0-20181209151446-772ced7fd4c2 (/home/marco/go/pkg
/mod/github.com/ugorji/go/codec@v0.0.0-20181209151446-772ced7fd4c2)
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
@marcoippolito I will be pushing out a v1.2 release around the end of next week. Just FYI, in case that helps.
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
Closing now after 3 weeks with no issues raised.
Thanks for all your help, folks!