cmd/go: "finding" lines always printed for dependency with seemingly consistent import path usage

[zikaeroh]

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/[email protected] 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.

[bcmills]

I suspect that this is a duplicate of #27063. What happens if you run go list all instead of go mod tidy?

[zikaeroh]

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

[zikaeroh]

Note that this output is the same with/without that replace directive.

[bcmills]

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.

[zikaeroh]

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...).

[bcmills]

Thanks for confirming.

[bcmills]

Duplicate of #27063

[agnivade]

@bcmills - Did you not mean to close this ?