Hi guys does anyone would know what is the issue with this package:
go: loading module retractions for github.com/googleapis/gax-go/v2#v2.0.1: parsing go.mod: go.mod:8:2: require google.golang.org/genproto: version "b98a9ff5e252" invalid: must be of the form v1.2.3
after doing go get -u ./... or how to work around to fix this ?
The go.mod file of the module you are trying to import is broken. As the message you posted says, the version number should start with "v" (see here)
It seems that the module was broken by a bot https://github.com/googleapis/gax-go/commit/735836c34b8124d657958d469998865569e14742
The solution would be to revert the commit on the googleapis/gax-go repository.
Related
I'm trying to use grafana/grafana/pkg/tsdb package in my module. I don't think this problem is specific to grafana but here it goes:
$ go get -u github.com/grafana/grafana/pkg/tsdb
go: finding github.com/inconshreveable/log15 latest
go: finding github.com/go-macaron/session latest
go: finding golang.org/x/oauth2 latest
go: finding github.com/teris-io/shortid latest
go: github.com/grafana/grafana/pkg/tsdb imports
github.com/go-xorm/core: github.com/go-xorm/core#v0.6.3: parsing go.mod:
module declares its path as: xorm.io/core
but was required as: github.com/go-xorm/core
It says that the package tsdb is importing xorm as github.com/go-xorm/core, but the module declares itself as xorm.io/core.
Looking at Grafana's go.mod file, it's using github.com/go-xorm/core and going to github.com/go-xorm/core, it says the project is now archived... and it's go.mod file indeed declared itself as xorm.io/core...
and suggestions on how I can resolve this issue?
edit: I also had luck just using a slightly older version:
go get github.com/grafana/grafana/pkg/tsdb#6.6.1
I tried a replace, which can work sometimes:
module foo
replace github.com/go-xorm/core => xorm.io/core v0.6.2
go 1.13
require (
...
but I get a type error.
Luckily it looks like there is a PR out to fix this issue: https://github.com/grafana/grafana/pull/22376
When I run go get -u github.com/onsi/ginkgo/ginkgo
till yesterday I had no issues. Specifically with fsnotify the output was like below
00:52:08 go: downloading gopkg.in/fsnotify.v1 v1.4.7
00:52:08 go: extracting gopkg.in/tomb.v1 v1.0.0-20141024135613-dd632973f1e7
00:52:08 go: extracting gopkg.in/fsnotify.v1 v1.4.7
Now I see this error while executing same command
11:50:39 go: gopkg.in/fsnotify.v1#v1.4.8: go.mod has non-....v1 module path "github.com/fsnotify/fsnotify" at revision v1.4.8
11:50:39 go get: error loading module requirements
What might have gone wrong here
Some module in the transitive dependencies of github.com/onsi/ginkgo/ginkgo added a requirement on some version of gopkg.in/fsnotify.v1, which resolves to the repository hosted at github.com/fsnotify/fsnotify.
However, the go.mod file in that repository declares its canonical import path to be github.com/fsnotify/fsnotify, not gopkg.in/fsnotify.v1.
If you are using Go 1.14, the rest of the error message (which seems to be truncated) should tell you exactly which dependency is using the non-canonical path. The long-term fix is to move that dependency over to the canonical path and upgrade your other dependencies such that gopkg.in/fsnotify.v1 is no longer required.
My coworker pushed a tag v3.0.1 before updating go.mod to have /v3 suffix (https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher). I have updated module path (go.mod) and all import paths (*.go) to fix it, tagged as v3.0.2.
Now the problem is:
go get -v git.example.com/owner/repo#v3.0.2
go: finding git.example.com/owner/repo v3.0.2
go: git.example.com/owner/repo#v0.0.0-20190722053407-d85c4f69ad17: go.mod has post-v0 module path "git.example.com/owner/repo/v3" at revision
d85c4f69ad17
Found this: go build keeps complaining that: go.mod has post-v0 module path
So, I deleted both v3.0.0 and v3.0.1 tags, pointed it to the latest commit, re-pushed but the problem still stand.
I noticed that go.mod still refered to the old version as an indirect dependency:
require (
git.example.com/owner.repo v0.1.2 // indirect
Even if I changed it to /v3 v3.0.2 it will be restored to v0.1.12 automatically.
Why?
Did I miss something?
Tue Jul 23 05:54:56 +07 2019
rm go.*
go mod init git.example.com/dependent/project
go mod tidy
and go.mod is updated correctly now:
require (
- git.example.com/owner/repo v0.1.2
+ git.example.com/owner/repo/v3 v3.0.2
but go get -v git.example.com/owner/repo#v3.0.2 still returned the error:
go: finding git.example.com/owner/repo v3.0.2
go: git.example.com/owner/repo#v0.0.0-20190722053407-d85c4f69ad17: go.mod has post-v0 module path "git.example.com/owner/repo/v3" at revision
d85c4f69ad17
(d85c4f69ad17 is the latest commit in master)
I noticed that there are both v0.1.2 and v3.0.2 in go.sum:
git.example.com/owner/repo v0.1.2 h1:mCGJEmyrFDTCGkRfUIORpqdrNkSONQ6K+AcTNgxqveY=
git.example.com/owner/repo v0.1.2/go.mod h1:FfUKnyPrARCtAXQZ3BQVJI7h2eJ0UpQBMLg4bNs4Kdc=
git.example.com/owner/repo/v3 v3.0.2 h1:mJtDKLeiP8vMRSZo08i/k/KDbIoZTlKW2aWu7DUBvMM=
git.example.com/owner/repo/v3 v3.0.2/go.mod h1:64LE0ts0Lk9InIQyhPYGmnxs6LZIl6H4Iorl1EXfqxo=
Please pay attention to my go get command:
go get -v git.example.com/owner/repo#v3.0.2
It should be:
go get -v git.example.com/owner/repo/v3#v3.0.2
for example you can replace repository with this hack: https://github.com/golang/go/wiki/Modules
require {
...
}
replace git.example.com/owner.repo v0.1.2 => git.example.com/owner.repo v3.0.2
or you can use go get at the commit hash you want:
go get git.example.com/owner.repo#af044c0995fe
go get will correctly update the dependency files (go.mod, go.sum).
For more information: https://github.com/golang/go/wiki/Modules#how-to-upgrade-and-downgrade-dependencies
or for last example you should clean cache
remove go.mod and go.sum
go cache clean
go mod vendor
Expanding on the answer from #quanta...
You are doing:
go get -v git.example.com/owner/repo#v3.0.2
Because it is a v3 module, the go get command should include a /v3 before the #:
go get -v git.example.com/owner/repo/v3#v3.0.2
Once a v3.x.y package is a module with its own go.mod, then whenenver you are operating with modules enabled, you pretty much always include the /v3 whenever you reference the v3.x.y module, including in:
arguments to go get on the command line
import statements in .go code for the consumer
require statements in a consumer's go.mod
replace or exclude statements in a consumer's go.mod
the module line of the v3 module's go.mod file
internal import statements in .go code inside the v3 module importing other packages in the v3 module
etc.
One way to think about it is that the module's name is now effectively git.example.com/owner/repo/v3, where its name includes the trailing /v3.
If you are a consumer of a vN module and need to update your import paths in your .go files to include the vN, then
github.com/marwan-at-work/mod is a commonly used tool from the community that automates adding the /vN in all the required spots. Separately, it also automates placing the /vN in all the required spots if you are a module author for a v2+ module.
From the "Semantic Import Versioning" section of the Go modules wiki:
If the module is version v2 or higher, the major version of the module must be included as a /vN at the end of the module paths used in go.mod files (e.g., module github.com/my/mod/v2, require github.com/my/mod/v2 v2.0.0) and in the package import path (e.g., import "github.com/my/mod/v2/mypkg").
I may have had a similiar issue where I updated a module to use the /v2 import path but go getting the module always returned an error about invalid go.mod
The solution was to go get -u github.com/<me>/<pkg>/v2
I have a package that I've uploaded to Github and am I am go getting the package on another server and keep getting the error:
go: github.com/golang/lint#v0.0.0-20190313153728-d0100b6bd8b3: parsing go.mod: unexpected module path "golang.org/x/lint"
I've deleted go.mod, go.sum and the vendor directory and updated all packages using
go get -u ./...
golang.org/x/lint is not in go.mod or go.sum or vendor directory yet I still get the error when trying to go get the package on my other server.
Note that, May 2021 (two years later) x/lint is fully deprecated. See issue 38968 and CL 318190.
Your error was seen in issue 32412 (related to issue 27900).
And go get -u has been fixed (CL 174099 "make get -u upgrade only modules providing packages")
What version of Go are you using (go version)?
$ go version
v1.12
The module yiigo has tag v3.0.0, but when I run go get github.com/iiinsomnia/yiigo, it gets the v2.1.0 and when I run go get github.com/iiinsomnia/yiigo#v3.0.0, it shows: go get github.com/iiinsomnia/yiigo#v3.0.0: unexpected end of JSON input
The primary issue seems to be that the v3.0.0 version of iiinsomnia/yiigo is missing the required /v3 at the end of the module line in its go.mod file:
https://github.com/iiinsomnia/yiigo/blob/v3.0.0/go.mod#L1
module github.com/iiinsomnia/yiigo <<<< wrong, missing required /v3 at end
go 1.12
require (
github.com/go-sql-driver/mysql v1.4.1-0.20190217072658-972a708cf979
...
That has since been corrected.
Because it is now a proper v3 module, the go get command should include a /v3 before the #:
module github.com/iiinsomnia/yiigo/v3#v3.2.2
From the Go modules wiki:
If the module is version v2 or higher, the major version of the module must be included as a /vN at the end of the module paths used in go.mod files (e.g., module github.com/my/mod/v2, require github.com/my/mod/v2 v2.0.0) and in the package import path (e.g., import "github.com/my/mod/v2/mypkg").
Also, it looks like a related issue was opened, with the theory being that the odd "unexpected end of JSON input" error might have come from some proxy:
https://github.com/golang/go/issues/30494
A way I've accomplished this in the past is by using git tags- for your case this should work fine.
Steps:
go get -u github.com/iiinsomnia/yiigo
cd ~/go/src/github.com/iiinsomnia/yiigo
git tag
locate tag release version you'd like to install within list
git checkout v3.0.0
go install
This will overwrite the package previously installed in your GOPATH with a new one for the specific tag version you have checked out.
Note: there is likely a better way to do this since the release of go modules.
This related post also provides alternative solutions on how to retrieve a specific version of a project's source code that may lend some help.