Viper doesn't work with etcd #658
Comments
|
go.sum |
|
etcd-io/etcd#10325 It is same problem |
Codec version has been changed in 1.1.2, but current tagged versions of etcd are compatible only with 1.1.1. Using viper/remote with incompatible versions of etcd and codec leads to error: panic: codecgen version mismatch: current: 8, need 10. Fixes spf13#658
This test can detect errors with dependencies like spf13#658.
Codec version has been changed in 1.1.2, but current tagged versions of etcd are compatible only with 1.1.1. Using viper/remote with incompatible versions of etcd and codec leads to error: panic: codecgen version mismatch: current: 8, need 10. Fixes spf13#658
This test can detect errors with dependencies like spf13#658.
Codec version has been changed in 1.1.2, but current tagged versions of etcd are compatible only with 1.1.1. Using viper/remote with incompatible versions of etcd and codec leads to error: panic: codecgen version mismatch: current: 8, need 10. Fixes spf13#658
|
I still have this problem,using the latest version of viper(v1.3.2) and |
|
I did |
|
@amarox I had the same problem. For now, It should be OK. I hope ugorji/go#43 can help you. |
|
same problem |
|
The solution in gin-gonic/gin#1897 may help you. I think the ultimate fix for this is to remove viper's indirect dependency on |
|
This is a major pain point for us trying to move forward to go modules based dependency management as many shared libraries depend on github.com/ugorji/go. Could we get a new release w/o the github.com/ugorji/go/codec dependency, please? |
|
A related thread: https://groups.google.com/forum/#!topic/golang-nuts/0mJh8SkaomA One workaround you can try is: From the modules doc:
Setting aside any particular workaround, though, it seems at least somewhat likely that a new release of viper is warranted, with an updated Would anyone here be interested in trying a PR for viper? @bep @spf13 @sagikazarmark any brief thoughts on a way to try to move this forward? |
|
The issue title currently says "etcd", but this is not specific just to ectd. Here is a playground example: https://play.golang.org/p/QvLwENa4pTp which fails with: |
Hm... I have seen that error in several projects lately. |
|
It's very pervasive. It seems like lots of things find their way back to I would guess viper is a large part of it because it is such a popular package, but it seems like everybody depended on Unless there is some change to how module resolution works with ambiguous packages, I'm not sure there's any better way to fix this than continuing to update project dependencies so that they no longer depend on an old version of (Maybe the problem is just that go modules so persistently pull in pseudo-versions like By the way, here is how viper gets to an old version of (etcd has since been updated to not even use |
|
Actually, it's interesting that all these issues are caused by a pseudo-version from before there was even a Maybe in situations like this, the go module solver could attempt to resolve the ambiguity by trying with a less specific path instead (by removing |
I don't think specificity helps: the problem is that there are too many providers of the package, not too few. That said, see golang/go#27899 for some possible ways the |
|
It is probably worth trying just deleting the older module path In a quick test: In other words, the problematic old And then |
FWIW, because there is no The package And it goes without saying that this is confusing... ;-) |
|
Good to know...seems odd that a command called |
|
Hi folks, Please see ugorji/go#299 and add your thoughts/ideas/etc. Thanks. |
|
I've created #705 to fix the borked github.com/ugorji/go/codec dep. |
|
@bep thanks! And @jadekler thanks for the PR! FWIW, my failing example from several comments back in #658 (comment) now no longer fails complaining about ambiguous import for https://play.golang.org/p/i6msmOVvznW @ugorji that is progress... (That playground example now fails with a different error compaining about fsnotify, but that is apparently because fsnotify doesn't support nacl/amd64p32, which means it fails on the playground... but that is actually a good sign for this particular issue, because it got past the |
|
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. |
I have error:
I tried
and had error:
The text was updated successfully, but these errors were encountered: