cmd/go: make the error from 'go get -u' more helpful when the current directory does not contain a package

[rvolosatovs]

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

$ go version
go version go1.13 linux/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
GO111MODULE="on"
GOARCH="amd64"
GOBIN="/home/rvolosatovs/.local/bin.go"
GOCACHE="/home/rvolosatovs/.local/cache/go-build"
GOENV="/home/rvolosatovs/.config/go/env"
GOEXE=""
GOFLAGS="-tags=tti"
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/rvolosatovs:/nix/store/b02sg3w3h50k3h8f53mix6ivd9zh8fm2-go-1.13/share/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/nix/store/b02sg3w3h50k3h8f53mix6ivd9zh8fm2-go-1.13/share/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/nix/store/b02sg3w3h50k3h8f53mix6ivd9zh8fm2-go-1.13/share/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="0"
GOMOD="/home/rvolosatovs/src/go.thethings.network/lorawan-stack/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 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build061535754=/tmp/go-build -gno-record-gcc-switches"

What did you do?

go get -u -v

Fails on go 1.13

The project contains both go.mod(https://github.com/rvolosatovs/lorawan-stack/blob/ce9328f83312201d231b4183413c969260b5a5a1/go.mod) and go.sum(https://github.com/rvolosatovs/lorawan-stack/blob/ce9328f83312201d231b4183413c969260b5a5a1/go.sum)

go mod tidy, go mod download and go mod vendor work fine

What did you expect to see?

Dependency update

What did you see instead?

go get .: cannot find package

[thepudds]

@rvolosatovs What happens if you try go get -u -v ./...?

If you dogo get -u ./... from your module root, it upgrades the direct and indirect dependencies of your module, exclusive of test dependencies.

From the Go 1.13 release notes:

In module-aware mode, go get with the -u flag now updates a smaller set of modules that is more consistent with the set of packages updated by go get -u in GOPATH mode. go get -u continues to update the modules and packages named on the command line, but additionally updates only the modules containing the packages imported by the named packages, rather than the transitive module requirements of the modules containing the named packages.

Note in particular that go get -u (without additional arguments) now updates only the transitive imports of the package in the current directory

The last sentence might be describing what you see.

Do you have any *.go files in your working directory when you do go get -u -v without any arguments? If not, then the go command might be complaining that you've asked to upgrade dependencies of the current package, but the current package does not exist (given a Go package is made up of *.go source files in a particular directory).

[rvolosatovs]

Adding a go file in the root directory with no build constraints fixed the issue. (TheThingsNetwork/lorawan-stack@29b8003)
Thanks, @thepudds

I suppose what I encountered is exactly what

Note in particular that go get -u (without additional arguments) now updates only the transitive imports of the package in the current directory

entails

[thepudds]

@rvolosatovs @bcmills what would you think about re-opening this as a tracking issue for a friendlier message here?

(The current message says go get ., but the user never typed .. The current message says cannot find package, but doesn't directly say what package it cannot find, etc.)

[rvolosatovs]

The error message is indeed very confusing for a user, who does not expect it.
Now that I know what caused the issue, it's clear what it means, but it was absolutely useless for me when I encountered it.
Note, that the error is valid in fact - the package go cannot find is ., i.e. the package in the current directory.
So I agree that the error message is far from being user-friendly in this exact (corner) case, but on the other hand go get -u implies go get -u . and in case of any other usage than go get -u the invocation would actually look like go get -u <pkg> and hence the error message would look like go get <pkg>: cannot find package, which is perfectly fine IMO.