cmd/go: "finding" lines always printed for dependency with seemingly consistent import path usage
zikaeroh opened this issue · 8 comments
What version of Go are you using (go version)?
$ go version go version go1.12.6 linux/amd64
Does this issue reproduce with the latest release?
Yes. Tip is slightly different (see later)
What operating system and processor architecture are you using (go env)?
go env Output
$ go env GOARCH="amd64" GOBIN="" GOCACHE="/home/jake/.cache/go-build" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOOS="linux" GOPATH="/home/jake/go" GOPROXY="" GORACE="" GOROOT="/usr/lib/go" GOTMPDIR="" GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64" GCCGO="gccgo" CC="gcc" CXX="g++" CGO_ENABLED="1" GOMOD="/home/jake/findingbug/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-build614075218=/tmp/go-build -gno-record-gcc-switches"
What did you do?
I want to pin a dependency (to use with gobin), so I use the tools.go pattern.
module findingbug
go 1.12
require github.com/maxbrunsfeld/counterfeiter/v6 v6.2.0
// +build tools
package tools
import (
_ "github.com/maxbrunsfeld/counterfeiter/v6"
)I perform operations with this in place, like go mod tidy, or a go get to do an update; something that modifies go.mod.
What did you expect to see?
Running go mod tidy with this setup prints nothing interesting, maybe a download once to get v6.2.0. If I were at v6.1.0, a go get can update it and again print maybe a finding/downloading line or two.
What did you see instead?
Any operation that modifies go.mod (I think that's the condition) constantly prints messages like these:
$ go mod tidy
go: finding github.com/maxbrunsfeld/counterfeiter/v6/fixtures/fixturesfakes latest
go: finding github.com/maxbrunsfeld/counterfeiter/v6/fixtures latest
go: finding github.com/maxbrunsfeld/counterfeiter latest
go: downloading github.com/maxbrunsfeld/counterfeiter v0.0.0-20190614042641-5e26f8d4cfe9
If I go into ~/go/pkg/mod/github.com/maxbrunsfeld/counterfeiter/v6@v6.2.0 and try to see if there's some bad import path, I find nothing. Every import path uses /v6 at the end, and the only usage without it is a go get example for use without modules.
Using gotip, less is printed, but it's still shown for every operation:
$ gotip version
go version devel +44c9354 Fri Jun 21 05:21:30 2019 +0000 linux/amd64
$ gotip mod tidy
go: finding github.com/maxbrunsfeld/counterfeiter latest
The only way I've found for this specific case to make at least the "downloading" go away is to do:
replace github.com/maxbrunsfeld/counterfeiter => github.com/maxbrunsfeld/counterfeiter/v6 v6.2.0
But the finding lines never go away (even on tip). Note that none of this prevents the binary from being built; go run and gobin all have no trouble building and running what I want (with or without that replace).
It's not clear to me what the issue is if both counterfeiter and my own code all use the /v6 import path consistently, but it's frustrating for many go invocations to print a bunch of stuff to stderr.
I suspect that this is a duplicate of #27063. What happens if you run go list all instead of go mod tidy?
Assuming you meant go list -m all (since go list all just told me "matched no packages"):
$ go list -m all
findingbug
github.com/fsnotify/fsnotify v1.4.7
github.com/golang/protobuf v1.2.0
github.com/hpcloud/tail v1.0.0
github.com/joefitzgerald/rainbow-reporter v0.1.0
github.com/maxbrunsfeld/counterfeiter/v6 v6.2.0
github.com/onsi/ginkgo v1.6.0
github.com/onsi/gomega v1.5.0
github.com/sclevine/spec v1.2.0
golang.org/x/crypto v0.0.0-20190308221718-c2843e01d9a2
golang.org/x/net v0.0.0-20190522155817-f3200d17e092
golang.org/x/sync v0.0.0-20190423024810-112230192c58
golang.org/x/sys v0.0.0-20190531175056-4c3a928424d2
golang.org/x/text v0.3.2
golang.org/x/tools v0.0.0-20190601110225-0abef6e9ecb8
gopkg.in/check.v1 v0.0.0-20161208181325-20d25e280405
gopkg.in/fsnotify.v1 v1.4.7
gopkg.in/tomb.v1 v1.0.0-20141024135613-dd632973f1e7
gopkg.in/yaml.v2 v2.2.1
Note that this output is the same with/without that replace directive.
No, I mean go list all, but I had missed the fact that you have a // +build tools constraint.
That probably implies go list -tags=tools all.
Ah, forgive me. I get this (truncated for the relevant lines):
$ go list -tags=tools all
go: finding github.com/maxbrunsfeld/counterfeiter/v6/fixtures/fixturesfakes latest
go: finding github.com/maxbrunsfeld/counterfeiter/v6/fixtures latest
go: finding github.com/maxbrunsfeld/counterfeiter latest
go: downloading github.com/maxbrunsfeld/counterfeiter v0.0.0-20190614042641-5e26f8d4cfe9
can't load package: package github.com/maxbrunsfeld/counterfeiter/v6/fixtures/fixturesfakes: unknown import path "github.com/maxbrunsfeld/counterfeiter/v6/fixtures/fixturesfakes": cannot find module providing package github.com/maxbrunsfeld/counterfeiter/v6/fixtures/fixturesfakes
# ...
github.com/maxbrunsfeld/counterfeiter/v6
github.com/maxbrunsfeld/counterfeiter/v6/arguments
github.com/maxbrunsfeld/counterfeiter/v6/command
github.com/maxbrunsfeld/counterfeiter/v6/fixtures
github.com/maxbrunsfeld/counterfeiter/v6/fixtures/aliased_package
github.com/maxbrunsfeld/counterfeiter/v6/fixtures/another_package
github.com/maxbrunsfeld/counterfeiter/v6/fixtures/go-hyphenpackage
github.com/maxbrunsfeld/counterfeiter/v6/generator
# ...
github.com/maxbrunsfeld/counterfeiter/v6/fixtures/fixturesfakes doesn't actually exist but is imported for a test. The repo's CI seems to run a go generate before running tests, so maybe I just need to go make an issue on their repo to check in their generated code (which they actually gitignore...).
Thanks for confirming.