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 module/import name mismatch while loading module retractions on forked/renamed module #41350

Closed
zikaeroh opened this issue Sep 11, 2020 · 7 comments
Assignees
Milestone

Comments

@zikaeroh
Copy link
Contributor

@zikaeroh zikaeroh commented Sep 11, 2020

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

$ go version
go version devel +07c1788357 Fri Sep 11 18:14:49 2020 +0000 linux/amd64

Does this issue reproduce with the latest release?

No, this works fine in Go 1.15. On tip, it fails.

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

go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/jake/.cache/go-build"
GOENV="/home/jake/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/jake/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/jake/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/jake/sdk/gotip"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/jake/sdk/gotip/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/jake/zikaeroh/hortbot/hortbot/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build245809118=/tmp/go-build -gno-record-gcc-switches"
GOROOT/bin/go version: go version devel +07c1788357 Fri Sep 11 18:14:49 2020 +0000 linux/amd64
GOROOT/bin/go tool compile -V: compile version devel +07c1788357 Fri Sep 11 18:14:49 2020 +0000
uname -sr: Linux 5.8.8-zen1-1-zen
/usr/lib/libc.so.6: GNU C Library (GNU libc) release release version 2.32.
gdb --version: GNU gdb (GDB) 9.2

What did you do?

This is a cut down version of something I see in one of my projects, where some dependency of a dependency (and so on) causes this.

package main

import _ "github.com/spf13/viper"

func main() {}

And a go.mod:

module some.tld/golistall

go 1.15

require github.com/spf13/viper v1.7.1

Run go list -u -m all.

What did you expect to see?

A listing of all modules, with possible upgrades listed. This command is used by tooling like gopls to offer upgrades as well.

What did you see instead?

go list -m: loading module retractions: github.com/coreos/bbolt@v1.3.5: parsing go.mod:
	module declares its path as: go.etcd.io/bbolt
	        but was required as: github.com/coreos/bbolt

viper requires github.com/coreos/bbolt@v1.3.2, which predates the addition of a go.mod. When this fork of bolt was turned into a module, it gained the new import path go.etcd.io/bbolt. I'm assuming that this breaks down with -u because it's scanning newer versions and finding the mismatch.

Normally, I'd say "viper should update its use to the new module path", but I'm not sure that this is going to really fix the issue if these sorts of mismatches are living happily in the wild. The code still builds, but it causes anyone who depends on it to no longer be able to run go list -u -m all seemingly without much recourse in a situation that worked in previous versions of Go.

I bisected the issue, assuming it was something related to the new all changes, but it's actually the -retracted CL. (On reflection, I didn't read the error message closely enough; it says "loading module retractions" right there!)

eb3e27ac1a9346c7c2669ba2b863811607eddeae is the first bad commit
commit eb3e27ac1a9346c7c2669ba2b863811607eddeae
Author: Jay Conrod <jayconrod@google.com>
Date:   Wed Apr 15 14:42:15 2020 -0400

    cmd/go: add -retracted flag to 'go list'
    
    The -retracted flag causes 'go list' to load information about
    retracted module module versions.
    
    When -retracted is used with -f or -json, the Retracted field is set
    to a string containing the reason for the retraction on retracted
    module versions. The string is based on comments on the retract
    directive. This field is also populated when the -u flag is used.
    
    When -retracted is used with -versions, retracted versions are shown.
    Normally, they are omitted.
    
    For #24031
    
    Change-Id: Ic13d516eddffb1b8404e21034f78cecc9896d1b8
    Reviewed-on: https://go-review.googlesource.com/c/go/+/228382
    Reviewed-by: Michael Matloob <matloob@golang.org>
    Reviewed-by: Bryan C. Mills <bcmills@google.com>

I'll preemptively cc @jayconrod and @bcmills, if that's okay. 🙂

@zikaeroh zikaeroh changed the title cmd/go: go list -m -u all fails with module/import name mismatch after -retracted CL on forked/renamed module cmd/go: go list -m -u all fails with module/import name mismatch while loading module retractions on forked/renamed module Sep 11, 2020
@zikaeroh zikaeroh changed the title cmd/go: go list -m -u all fails with module/import name mismatch while loading module retractions on forked/renamed module cmd/go: go list -u -m all fails with module/import name mismatch while loading module retractions on forked/renamed module Sep 11, 2020
@jayconrod jayconrod self-assigned this Sep 11, 2020
@jayconrod jayconrod added this to the Go1.16 milestone Sep 11, 2020
@bcmills
Copy link
Member

@bcmills bcmills commented Sep 11, 2020

Neat find! Thanks for testing and reporting.

@bcmills
Copy link
Member

@bcmills bcmills commented Sep 14, 2020

@jayconrod, I wonder if we should expand the retract syntax to allow the directive to specify the module to which the retraction should apply.

If I have a repo at, say, github.com/golang/lint, that declares a different module path (say, golang.org/x/lint), that repo should probably be allowed to retract versions of github.com/golang/lint even though that is not its current module path.

@jayconrod
Copy link
Contributor

@jayconrod jayconrod commented Sep 14, 2020

@bcmills I wonder if that should be combined with aliasing? A while back, I think you had a design for a directive specifying paths by which a module was previously known. If we had that, then a retraction of golang.org/x/lint@v1.2.3 could cover github.com/golang/lint@v1.2.3 as well.

@bcmills
Copy link
Member

@bcmills bcmills commented Sep 14, 2020

Hmm, that's true. And the version range for the previous path(s) shouldn't overlap with the version range for the current path anyway. (The tags on the repo would be ambiguous.)

@bcmills
Copy link
Member

@bcmills bcmills commented Sep 14, 2020

So probably we should just ignore the declared module path for the purpose of retractions‽

@jayconrod
Copy link
Contributor

@jayconrod jayconrod commented Sep 14, 2020

So probably we should just ignore the declared module path for the purpose of retractions‽

Yeah, I think that would work. And we don't need any new syntax for that, which is very nice.

@gopherbot
Copy link

@gopherbot gopherbot commented Sep 18, 2020

Change https://golang.org/cl/255961 mentions this issue: cmd/go/internal/modload: don't report path errors when loading retractions

@gopherbot gopherbot closed this in 0b71ce6 Sep 18, 2020
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
4 participants
You can’t perform that action at this time.