cmd/go: get -u -t fails to update go.mod when "no non-test Go files in path"

[kbalk]

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

$ go version
go version go1.15.3 linux/amd64

Does this issue reproduce with the latest release?

Did not test on the latest version.

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

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/kbalk/.cache/go-build"
GOENV="/home/kbalk/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/kbalk/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/kbalk/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/kbalk/plus3it/terraform-aws-org-new-account-iam-role/tests/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-build005428471=/tmp/go-build -gno-record-gcc-switches"

What did you do?

I have a Go module (module_test.go) for testing a Terraform init/plan/apply. All I have and need in terms of programming is this single go file with a package name of testing. I have a go.mod file as shown below. The directory tardigrade-ci/tests mentioned in go.mod will contain module_test.go, go.mod, go.sum and some Terraform files.

I ran go get -u -t to get updated versions in go.mod. In particular, github.com/stretchr/testify had released an updated version.

module tardigarde-ci/tests

go 1.15

require (
	github.com/gruntwork-io/terratest v0.32.8
	github.com/stretchr/testify v1.6.1
	golang.org/x/net v0.0.0-20201021035429-f5854403a974 // indirect
	golang.org/x/sys v0.0.0-20210119212857-b64e53b001e4 // indirect
)

replace github.com/gruntwork-io/terratest v0.32.8 => github.com/ffernandezcast/terratest v0.28.6-0.20201201084725-13e8a4c156b8

What did you expect to see?

Updated version for github.com/stretchr/testify; instead of v1.6.1, expected to see v1.7.0.

What did you see instead?

go.mod file was unchanged. Will updates to go.mod only occur when there are non-test files?

Note: I also tried running go clean -modcache, then running go get -u -t and that had no effect.

[jayconrod]

cc @bcmills @matloob

[jayconrod]

I thought this might be a duplicate of #33526, but it still reproduces at tip.

[bcmills]

This invocation is missing the -d flag.

go get -u -t requests that the go command do all of:

1. Fetch and update all of the dependencies of the package named on the command line, or the current package (if no other package is named), along with the dependencies of its test.
2. Build the named package.

This command is failing in step (2), which causes the overall operation to fail. In CL 255970 (for #41315), we decided that we should only update the go.mod file if the go get command overall succeeds.

The -d flag explicitly requests to skip step (2). If that is done here, the dependencies of the (named or implicit) test-only package should be updated as requested.

[kbalk]

I've tried go get -u -t -d and go.mod is still not updated.

[jayconrod]

@kbalk Is go get -u -t -d still showing an error, or only not updating go.mod? If the latter, does the package in the current directory import github.com/stretchr/testify?

[kbalk]

There's no error, but there's no change to go.mod (I've since removed the indirects in go.mod):

go get -u -t -d tardigrade-ci/tests
go: github.com/russross/blackfriday/v2 upgrade => v2.1.0
go: github.com/stretchr/testify upgrade => v1.7.0
go: github.com/jmespath/go-jmespath upgrade => v0.4.0
go: google.golang.org/appengine upgrade => v1.6.7
go: gopkg.in/yaml.v3 upgrade => v3.0.0-20210107192922-496545a6307b
go: golang.org/x/sys upgrade => v0.0.0-20210319071255-635bc2c9138d
go: github.com/davecgh/go-spew upgrade => v1.1.1
go: github.com/urfave/cli upgrade => v1.22.5
go: github.com/go-sql-driver/mysql upgrade => v1.5.0
go: golang.org/x/net upgrade => v0.0.0-20210316092652-d523dce5a7f4
go: github.com/go-errors/errors upgrade => v1.1.1
go: github.com/google/uuid upgrade => v1.2.0
go: github.com/jinzhu/copier upgrade => v0.2.8
go: github.com/gruntwork-io/terratest upgrade => v0.32.15
go: github.com/aws/aws-sdk-go upgrade => v1.38.0
go: github.com/cpuguy83/go-md2man/v2 upgrade => v2.0.0
go: github.com/boombuler/barcode upgrade => v1.0.1
go: golang.org/x/crypto upgrade => v0.0.0-20210317152858-513c2a44f670
go: github.com/pmezard/go-difflib upgrade => v1.0.0
go: github.com/gruntwork-io/gruntwork-cli upgrade => v0.8.2
go: github.com/pquerna/otp upgrade => v1.3.0
go get: github.com/gruntwork-io/gruntwork-cli@v0.7.0 updating to
	github.com/gruntwork-io/gruntwork-cli@v0.8.2: parsing go.mod:
	module declares its path as: github.com/gruntwork-io/go-commons
	        but was required as: github.com/gruntwork-io/gruntwork-cli

[bcmills]

go get: github.com/gruntwork-io/gruntwork-cli@v0.7.0 updating to
	github.com/gruntwork-io/gruntwork-cli@v0.8.2: parsing go.mod:
	module declares its path as: github.com/gruntwork-io/go-commons
	        but was required as: github.com/gruntwork-io/gruntwork-cli

That is an error, is it not?

[kbalk]

Yes ... my apologies, I was thinking of a command line error.

[bcmills]

FWIW, in Go 1.16 the explicit versions on the command line should serve as upper bounds for the implicit -u upgrades. So you could try:

$ go get -u -t -d tardigrade-ci/tests github.com/gruntwork-io/gruntwork-cli@v0.7.0