Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: go list -u -m all fails with: loading module retractions for X: no matching versions for query "latest" #45305

Closed
ryancurrah opened this issue Mar 30, 2021 · 5 comments
Assignees
Labels
Milestone

Comments

@ryancurrah
Copy link

@ryancurrah ryancurrah commented Mar 30, 2021

What version of Go are you using (go version)?

╰─ go version
go version go1.16.2 darwin/amd64

Does this issue reproduce with the latest release?

Yes. It is reproducible in Go 1.16 or higher.

It is not reproducible on versions older than 1.16 because the retract statement is new in 1.16.

What operating system and processor architecture are you using (go env)?

go env Output
╰─  go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/rcurrah/Library/Caches/go-build"
GOENV="/Users/rcurrah/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/rcurrah/code/golang/pkg/mod"
GONOPROXY="go.acme.dev/*"
GONOSUMDB="go.acme.dev/*"
GOOS="darwin"
GOPATH="/Users/rcurrah/code/golang"
GOPRIVATE="go.acme.dev/*"
GOPROXY="https://go-proxy.acme.dev"
GOROOT="/Users/rcurrah/.go/current"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/Users/rcurrah/.go/current/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="go1.16.2"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/rcurrah/retractfail/go.mod"
CGO_CFLAGS="-O0 -g -I/usr/local/include/zookeeper"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/34/n05pjx4x7n3_cv9qt_3qqdpw0000gn/T/go-build466804611=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

Created an example module that imports the github.com/juju/utils module package which is causing go list -u -m all to fail.

mkdir retractfail
cd retractfail
go mod init github.com/ryancurrah/retractfail
touch main.go

Edit main.go.

package main

import _ "github.com/juju/utils"

func main() {}
go get github.com/juju/utils@v0.0.0-20200116185830-d40c2fe10647
go list -u -m all

What did you expect to see?

I expected to see a list of modules and module versions.

╰─ go version
go version go1.15.10 darwin/amd64

╰─ go list -u -m all
github.com/ryancurrah/retractfail
github.com/creack/pty v1.1.9 [v1.1.11]
github.com/juju/ansiterm v0.0.0-20160907234532-b99631de12cf [v0.0.0-20180109212912-720a0952cc2a]
github.com/juju/clock v0.0.0-20190205081909-9c5c9712527c
github.com/juju/cmd v0.0.0-20171107070456-e74f39857ca0 [v0.0.0-20200108104440-8e43f3faa5c9]
github.com/juju/collections v0.0.0-20200605021417-0d0ec82b7271
github.com/juju/errors v0.0.0-20200330140219-3fe23663418f
github.com/juju/gnuflag v0.0.0-20171113085948-2ce1bb71843d
github.com/juju/httpprof v0.0.0-20141217160036-14bf14c30767
github.com/juju/loggo v0.0.0-20200526014432-9ce3a2e09b5e
github.com/juju/mutex v0.0.0-20171110020013-1fe2a4bf0a3a [v0.0.0-20180619145857-d21b13acf4bf]
github.com/juju/retry v0.0.0-20180821225755-9058e192b216
github.com/juju/testing v0.0.0-20201216035041-2be42bba85f3
github.com/juju/utils v0.0.0-20200116185830-d40c2fe10647
github.com/juju/utils/v2 v2.0.0-20200923005554-4646bfea2ef1
...

What did you see instead?

I saw an error related to module retractions and the module github.com/juju/utils.

╰─ go version
go version go1.16.2 darwin/amd64

╰─ go list -u -m all
go list -m: loading module retractions for github.com/juju/utils@v0.0.0-20200116185830-d40c2fe10647: no matching versions for query "latest"
@ryancurrah
Copy link
Author

@ryancurrah ryancurrah commented Mar 30, 2021

One comment I have is that the modules name is github.com/juju/utils/v2 https://github.com/juju/utils/blob/master/go.mod#L1.

There are no v2 tags in the repository though: https://github.com/juju/utils/tags.

That's some bad juju.

@jayconrod jayconrod added the NeedsFix label Mar 31, 2021
@jayconrod jayconrod added this to the Go1.17 milestone Mar 31, 2021
@jayconrod jayconrod self-assigned this Mar 31, 2021
@jayconrod
Copy link
Contributor

@jayconrod jayconrod commented Mar 31, 2021

Thanks for reporting this!

When loading retractions, we don't normally require that the module path in go.mod matches the path we were looking for. It should be possible to retract versions with an incorrect module path, or versions that were tagged before a go.mod file was added.

Looks like that's causing problems in this case though. We shouldn't attempt to load retractions if the module path matches except for the major version suffix.

And in any case, a failure to load retractions probably shouldn't be fatal for go list -u -m.

For now, you can work around this using the -e flag.

@ryancurrah
Copy link
Author

@ryancurrah ryancurrah commented Mar 31, 2021

Thank you! Quite a few tools in the wild use this method to auto-update modules and will break when this error occurs. Unless like you mentioned, add the -e flag.

Is there any downside/things I should be aware of when using the -e flag?

@jayconrod
Copy link
Contributor

@jayconrod jayconrod commented Mar 31, 2021

Is there any downside/things I should be aware of when using the -e flag?

No real downsides; -e means go list will continue after an error occurs and will print as much as it can. Errors are still visible in the -f and -json output.

@gopherbot
Copy link

@gopherbot gopherbot commented Apr 1, 2021

Change https://golang.org/cl/306572 mentions this issue: cmd/go: in 'go list -m', ignore errors loading retractions

@gopherbot gopherbot closed this in 23e1d36 Apr 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants