cmd/go: "go get" can fail in a confusing way on the module path

[mvdan]

I found this weird error while writing a reproducer for #44961. Using x/tools as an example:

$ go version
go version devel +cf59850466 Wed Mar 10 09:01:05 2021 +0000 linux/amd64
$ cd src/tools
$ git checkout -q 44abc2a71b321b77c0a579d8c5bf2704d648c9e0
$ go get -d golang.org/x/tools
go get golang.org/x/tools: unrecognized import path "golang.org/x": parse https://golang.org/x?go-get=1: no go-import meta tags ()
$ go get -d golang.org/x/tools@latest
go get: can't request version "latest" of the main module (golang.org/x/tools)
$ go get -d golang.org/x/tools@master
go get: can't request version "master" of the main module (golang.org/x/tools)

I'm not sure why the first go get gives that weird error message. I would expect the three commands to error in the same way.

[jayconrod]

I think the can't request version "latest" of the main module messages are correct.

unrecognized import path "golang.org/x" is weird and confusing. I'm guessing that only comes up if the argument is the main module path? The go command would disqualify that when searching for packages, so it would be as if you typed go get golang.org/x, in which case that would be the correct message.

We should probably treat go get golang.org/x/tools just like go get golang.org/x/tools@upgrade. Technically, you might be looking for a package with the same path as the main module that actually is provided by another module, but it's unlikely.

[mvdan]

Technically, you might be looking for a package with the same path as the main module that actually is provided by another module, but it's unlikely.

I think that falls under "noone should ever ever do this", so I don't think the error message should mention a parent module. I don't think we should even try to look for a parent module.

[gopherbot]

Change https://golang.org/cl/331749 mentions this issue: cmd/go: do not go get main module inside its directory

[bcmills]

go get -d golang.org/x/tools is requesting that we download the package-or-module golang.org/x/tools. There is no such package, but if golang.org/x/tools itself is the main module, then it is the latest version of itself and arguably the command should succeed without error.

That is, the lack of a corresponding package should cause the path to be interpreted as a module path, and then nothing should change because the main module is already (invariantly) the latest version of itself.

[bcmills]

#37700 is closely related.

[iwdgo]

Issue was incidentally fixed by commit 109c13b64f815230af65af5c21e67cd7baa62a05 which merged dev.cmdgo development.

> gotip version
go version devel go1.18-ee91bb8319 Tue Sep 14 02:53:17 2021 +0000 windows/amd64
>gotip get  -d golang.org/x/tools
go: downloading golang.org/x/tools v0.1.5

It seems that issue can be closed for now.