cmd/go: mod tidy adds indirect test dependencies

[extemporalgenome]

go mod tidy often adds dependencies which will never get used, such as indirect test dependencies (test-related dependencies of dependencies), or dependencies via likely-to-be-unused build tags (such as gopherjs dependencies for projects that support the js build tag.

This issue is compounded when followed by go mod vendor, which includes these dependencies as well.

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

$ go version
go version go1.11.4 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="/Users/kevingillette/usr/bin"
GOCACHE="/Users/kevingillette/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/kevingillette/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/kevingillette/sandbox/modules/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/ct/t6rzgvn537bcjcy8n_7g3z2r0000gq/T/go-build062165011=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

// go.mod
module github.com/user/xyz

// main.go
package main

import _ "github.com/afex/hystrix-go/hystrix"

func main() {}

$ go mod tidy

What did you expect to see?

// go.mod
module github.com/user/xyz

require (
	github.com/afex/hystrix-go v0.0.0-20180502004556-fa1af6a1f4f5
)

What did you see instead?

// go.mod
module github.com/user/xyz

require (
	github.com/afex/hystrix-go v0.0.0-20180502004556-fa1af6a1f4f5
	github.com/gopherjs/gopherjs v0.0.0-20181103185306-d547d1d9531e // indirect
	github.com/jtolds/gls v4.2.1+incompatible // indirect
	github.com/smartystreets/assertions v0.0.0-20180927180507-b2de0cb4f26d // indirect
	github.com/smartystreets/goconvey v0.0.0-20181108003508-044398e4856c // indirect
)

hystrix-go has no third-party dependencies except in test code. hystrix-go tests depend on goconvey, which in turn depend on gls, which depends on gopherjs in a file with a js build tag (as an aside: it seems many paths lead back to gopherjs when go modules are involved).

I would expect go.mod to not contain indirect test dependencies (it's not the responsibility of this project to run its dependencies' tests). Further, I would like some level of control in the go.mod file over build tags that are included or excluded. For example, excluding (or not including) the js tag from being considered in module operations, such as via a go.mod "tags" directive, would avoid much of this issue.

[agnivade]

Duplicate of #27633 ?

[bcmills]

I would expect go.mod to not contain indirect test dependencies

See previous discussion in #26626.
See also the discussion in #26955.

(it's not the responsibility of this project to run its dependencies' tests).

That's debatable:

• Bugs and regressions in transitive dependencies can exist, although they'll hopefully be rare. If you have some dependency M1 that itself depends on M2, and you upgrade M2 to a higher version (for example, due to a requirement of some other dependency M3), then you should run M1's tests to ensure that it is not broken by a bad interaction with the selected version of M2.
• Even if the set of transitive dependencies is exactly the same, platform-specific bugs can and do occur. If you re-run the tests for M1 on your specific platform, you stand a better chance of detecting those bugs.

Further, I would like some level of control in the go.mod file over build tags that are included or excluded. For example, excluding (or not including) the js tag from being considered in module operations, such as via a go.mod "tags" directive, would avoid much of this issue.

That's #25873. (In general, please stick to one decision per issue filed: when we close an issue — especially if it turns out to be a duplicate! — it's easy to miss an interesting secondary point.)

[bcmills]

Closing as a duplicate of the aforementioned issues.