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

Jump to bottom

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

Closed
zikaeroh opened this issue Jun 21, 2019 · 8 comments
Closed

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

zikaeroh opened this issue Jun 21, 2019 · 8 comments
Labels
FrozenDueToAge modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Milestone
Go1.14

Comments

@zikaeroh
Copy link
Contributor

zikaeroh commented Jun 21, 2019 •
edited

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.
@bcmills
Copy link
Contributor

bcmills commented Jun 21, 2019

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

@bcmills bcmills added modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. labels Jun 21, 2019
@bcmills bcmills added this to the Go1.14 milestone Jun 21, 2019
@zikaeroh
Copy link
Contributor Author

zikaeroh commented Jun 21, 2019 •
edited

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
Copy link
Contributor Author

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

@bcmills
Copy link
Contributor

bcmills commented Jun 21, 2019

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.

@bcmills bcmills added WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. and removed WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. labels Jun 21, 2019
@zikaeroh
Copy link
Contributor Author

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

@zikaeroh zikaeroh mentioned this issue Jun 22, 2019
Closed
@bcmills
Copy link
Contributor

bcmills commented Jun 24, 2019

Thanks for confirming.

@bcmills
Copy link
Contributor

bcmills commented Jun 24, 2019

Duplicate of #27063

@bcmills bcmills marked this as a duplicate of #27063 Jun 24, 2019
@agnivade
Copy link
Contributor

@bcmills - Did you not mean to close this ?

@bcmills bcmills closed this as completed Jun 25, 2019
@zikaeroh zikaeroh mentioned this issue Aug 18, 2019
Closed
@golang golang locked and limited conversation to collaborators Jun 24, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Projects
None yet
Milestone
Go1.14
Development

No branches or pull requests
4 participants
@agnivade @bcmills @gopherbot @zikaeroh