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 mod why lies #31351

Closed
mirtchovski opened this issue Apr 8, 2019 · 6 comments
Closed

cmd/go: go mod why lies #31351

mirtchovski opened this issue Apr 8, 2019 · 6 comments
Labels
Documentation 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

Comments

@mirtchovski
Copy link
Contributor

mirtchovski commented Apr 8, 2019

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

go version go1.12.1 darwin/amd64

Does this issue reproduce with the latest release?

Yes

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

go env Output
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/me/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/me/go"
GOPROXY=""
GORACE=""
GOROOT="/Users/me/sdk/go1.12.1"
GOTMPDIR=""
GOTOOLDIR="/Users/me/sdk/go1.12.1/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/me/orbital/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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/sp/06p28g2d0vs7gd2vhf26wl9m0000gn/T/go-build849154512=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

$ grep bson go.mod 
$ grep labix go.mod
        labix.org/v2/mgo v0.0.0-20140701140051-000000000287 // indirect
$ go mod why labix.org/v2/mgo
# labix.org/v2/mgo
(main module does not need package labix.org/v2/mgo)
$ go mod why labix.org/v2/mgo/bson
# labix.org/v2/mgo/bson
/very/important/package
github.com/nats-io/go-nats-streaming
github.com/nats-io/go-nats-streaming.test
github.com/nats-io/nats-streaming-server/server
github.com/hashicorp/go-msgpack/codec
github.com/hashicorp/go-msgpack/codec.test
labix.org/v2/mgo/bson
$ go mod vendor
$ find vendor -name bson
$

What did you expect to see?

At least some mention of the package "bson" anywhere in go mod's output.

What did you see instead?

Zero mention of the package "bson" anywhere in go mod's output.

@mirtchovski
Copy link
Contributor Author

also, there doesn't seem to be an import "bson" anywhere in the vendor/ directory:

$ find vendor -type f -print0 | xargs -0 grep bson
vendor/gopkg.in/yaml.v2/yaml.go:// The code in this section was copied from mgo/bson.

the problem is that the go mod tool always tries to download, cache, and reference this repository, even though there appears to be no need for it. this is causing grief primarily because it requires specialized tools to download (bzr).

@ALTree ALTree added this to the Go1.13 milestone Apr 9, 2019
@ALTree ALTree added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. modules labels Apr 9, 2019
@bcmills
Copy link
Contributor

bcmills commented Apr 17, 2019

go mod vendor prunes out tests of dependencies. go mod why does not.

@bcmills
Copy link
Contributor

bcmills commented Apr 17, 2019

@mirtchovski, the need for specialized tools will be mitigated by public module proxies. (And note that if labix.org/v2/mgo/bson isn't actually needed to resolve any direct imports in the packages you're building and testing, then you only need its go.mod file.)

go mod why seems to be giving you correct information: go mod why labix.org/v2/mgo searches for a package dependency, not a module dependency. (For the latter, you would want go mod why -m labix.org/v2/mgo.)

So it seems like this is, at best, a documentation issue. Did any particular document point you toward the use of go mod why? If so, perhaps we can clarify it.

@bcmills bcmills added Documentation WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. labels Apr 17, 2019
@mirtchovski
Copy link
Contributor Author

I believe I missed the -m from go mod why. With that it tells me exactly what I wanted. You can close this.

@meling
Copy link

meling commented Mar 6, 2020

This has bitten me many times now, and I find it confusing. How do I know whether or not something in my go.mod file is a package or module? My primary use of go mod why is to find out why go.mod contains a dependency; are there any other uses?

Whether or not my dependency is a package or module, is confusing to me (and probably others), and I would argue that the go mod why command should return a result either way. If the tool finds that the main module does not depend on the supplied package it should check if it depends on a corresponding module instead, obviating the need for the -m flag. Be helpful to users; make the default use case easy.

@jayconrod
Copy link
Contributor

@meling This issue is closed and is no longer tracked. If you want to propose a change or report a bug, please open a new issue.

@golang golang locked and limited conversation to collaborators Mar 9, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Documentation 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
Development

No branches or pull requests

6 participants