Thank you for this report @davecheney!

Kindly paging @bcmills @rsc.

Seems to not be working for me, either:

$ cd /tmp/whatever && unset GOPATH && go get cloud.google.com/go@v0.30.0
go: cannot use path@version syntax in GOPATH mode

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

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

Go get does not take path@version for me. I've filed #29659, since that appears to be different from the go run case that this issue was describing. (happy to dedupe if you prefer the conversation to happen here)

Can someone take a look at this please?

Example from https://golang.org/cmd/go/#hdr-Module_aware_go_get which is go get golang.org/x/text@v0.3.0 doesn't work and fails with the same error when GOPATH environment variable is not set.

This is breaking go-get’s ability as a package manager as the support for the go get -v github.com/rakyll/hey@v0.1.1 syntax is currently not working.

@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.

@bcmills I'm still seeing this despite I'm not running in GOPATH mode. go get or go build uses modules just fine when I don't specify a @version syntax.

Here's a minimal repro with go1.12

dir=$(mktemp -d)

cd $dir

# write a go.mod to indicate go111module=on
echo 'module foo' > go.mod

go get module syntax uses go.mod file:

# unset all env vars, with the exception of $HOME (mock it) and $PATH (inherit it)

env -i HOME="$PWD/mock-home" PATH="$PATH" go build -o ./httpstat github.com/davecheney/httpstat

    go: finding github.com/davecheney/httpstat v1.0.0
    go: downloading github.com/davecheney/httpstat v1.0.0
    go: extracting github.com/davecheney/httpstat v1.0.0
    ...
    (works)

go get module@1.0.0 syntax is not working in the same setup:

env -i HOME="$PWD/mock-home" PATH="$PATH" go build -o ./httpstat github.com/davecheney/httpstat@1.0.0

can't load package: package github.com/davecheney/httpstat@1.0.0: can only use path@version syntax with 'go get'

Would you still suggest I'm in "GOPATH mode"?

@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'”.

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.

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.

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.

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.

As I understand it, path@version should be used in Golang specifically for version maintenance. Hence @smikulcik comment to run the command in directory with go.mod file makes sense. Go will try to download the repository to your src folder from Github and will try to maintain the version in the mod file.

$ docker run -it golang:1.15-alpine
/go # echo $GOPATH
/go
/go # go run -v github.com/user/project@test
package github.com/user/project@test: can only use path@version syntax with 'go get'
/go # go install github.com/user/project@test
package github.com/user/project@test: can only use path@version syntax with 'go get'
/go # go get -u github.com/user/project@test
go: cannot use path@version syntax in GOPATH mode
/go # unset GOPATH
/go # echo $GOPATH

/go # go get -u github.com/user/project@test
go: cannot use path@version syntax in GOPATH mode <- I unset it! Yes, I know what the docs say, but still.
/go # export GO111MODULE=on
/ # go get -u github.com/user/project@test
go: downloading github.com/user/project v1.0.0-date-sha <- Should be test branch @latest, but that's separate.

@nivekastoreth FWIW I've written Go for the last five years and this is frustrating for me too.

These error messages are not helpful. Users should not need search the Internet for this error message to install an app from a git repository in an expected way. What steps can we take to make this just work and fix this user/developer experience? The answer is not "RTFM" Essays about Go mod version-specific pitfalls and workarounds shouldn't need exist. What can we do?

Practical example: I want to use Go-jsonnet (https://github.com/google/go-jsonnet), and I need a feature (TOML output) that has been added later than the most recent label in the git repository. The official installation instructions are

go get github.com/google/go-jsonnet/cmd/jsonnet

which installs the last label. Game over for my TOML files.

Plausible workarounds are all ridiculous:

• I can wait and maybe, sooner or later, possibly even this winter, a new label will be made and afterwards 'go get -u github.com/google/go-jsonnet/cmd/jsonnet' will install a suitable version.
• I can figure out how to replace the globally installed jsonnet with the result of compiling a current checkout of the go-jsonnet repository, as if I were actually developing go-jsonnet.
• I can attempt to find a silly incantation to convince 'go get' to do what I want. Probably impossible by design.

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