go: cmd/go: run gives conflicting advice when using path@version syntax

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

% go version go version devel +97d5cb24b1 Sat Dec 22 09:37:04 2018 +0000 linux/amd64

Does this issue reproduce with the latest release?

unknown

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

go env Output
% go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/dfc/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH=""
GOPROXY=""
GORACE=""
GOROOT="/home/dfc/go"
GOTMPDIR=""
GOTOOLDIR="/home/dfc/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
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-build125128327=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Go 1.12beta1 (tip) does not permit @version syntax unless modules explicitly enabled, even if GOPATH is unset

% unset GOPATH && go run -v github.com/davecheney/httpstat@1.0.0
package github.com/davecheney/httpstat@1.1.0: cannot use path@version syntax in GOPATH mode

What did you expect to see?

env GO111MODULE=on go run -v github.com/davecheney/httpstat@1.0.0

would download and build httpstat v1.0.0

What did you see instead?

% unset GOPATH && env GO111MODULE=on go run -v github.com/davecheney/httpstat@1.0.0
missing $GOPATH

Running without modules enabled tells me I must enable modules even thought I don’t have GOPATH set. Running with modules enable tells me I must set GOPATH.

lucky(/tmp) % env GO111MODULE=on GOPATH=/tmp/ go run -v github.com/davecheney/httpstat@1.0.0
package github.com/davecheney/httpstat@1.0.0: can only use path@version syntax with 'go get'

Setting both tells me that this isn’t supported.

a. Can go run path@version be supported? If not, why not? b. Can the error messages be improved make it clearer sooner that the operation will not succeed once the correct permutation of environment variables is discovered.

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Reactions: 8
  • Comments: 16 (7 by maintainers)

Most upvoted comments

Thanks to @smikulcik’s comment go get is at least minimally functional.

As someone who doesn’t program in go and only uses it to install utilities written in go, it’s extremely frustrating spending an hour trying to figure out how to install a simple application only to find out I have to pretend to be working on a project in order to install a version of a utility that’s needed.

With Go 1.13, also running into

imports github.com/diskfs/go-diskfs/filesystem@squashfs: cannot use path@version syntax in GOPATH mode

This is so annoying. Especially because it does not tell one what to do.

Hit this as well in #29575. Closing that as duplicate.

@ahmetb, this issue is about the diagnostic messages. If go get is not actually behaving as documented, please file that as a separate issue.

That said, from the detail in #29575 it appears that you are, in fact, running in GOPATH mode. Per https://golang.org/cmd/go/#hdr-Preliminary_module_support:

If GO111MODULE=auto or is unset, then the go command enables or disables module support based on the current directory. Module support is enabled only when the current directory is outside GOPATH/src and itself contains a go.mod file or is below a directory containing a go.mod file.

Change https://golang.org/cl/282121 mentions this issue: cmd/go: make hints in error messages more consistent

From what I can tell, you just have to be in a package that has a go.mod file. Then you can get a particular version.

Only go get and module-manipulation commands take path@version. go build, go run, etc do not.

@ahmetb, this issue is about the go command giving conflicting advice.

The advice from the commands you posted above does not conflict: it correctly indicates that, in module mode (which you are clearly in), you “can only use path@version syntax with ‘go get’”.