go get requests to build a binary. If you know that what you want is just the module (and not the binary at the root of that module), go get -d informs the go command that it should stop without attempting to build such a binary.

It may be that we should suppress the error without -d anyway, though. (See #29268, which is very closely related.)

#40145 is a duplicate of this issue, but that case seems more serious. go get -d fails when given a module path where the module root directory contains ignored .go files. The intent of the command is to update the dependency, not to build anyway.

I think this is happening because go get tries to decide fairly early whether each argument refers to a package or a module. If an argument is a module path, and there are no .go files at the module root, it's assumed to be a module path, and go get will not attempt to load a package. In this case, there are .go files, even though they're ignored, so go get tries and fails to load the package.

go get should probably handle the error from modload.ImportPathsQuiet more gracefully in this case.

Thanks, @jayconrod! Should I ping the protobuf maintainers about this? If this won't be fixed until 1.16, they probably want to work around the issue by moving the file until most developers are on 1.16 or later. FYI @dsnet

I think it would be good to put in a workaround for this. The file in question, integration_test.go seems like it could be moved out of the root directory.

Unfortunately, I think we're too deep in the freeze to land a bug fix for 1.15. Hopefully though that means 1.15 will be out on time and we'll have a longer development window for 1.16!

As of Go 1.16, go get now does suppress this error if the -d flag is set (see CL 289769), but not otherwise (because go get is being asked to actually build the package).

We should probably suppress it when the -d flag is not set, too, since we're phasing out the need for -d in general (see #43684).

Change https://golang.org/cl/297009 mentions this issue: cmd/go: suppress errors for 'go get' of module paths that are also constrained-out packages

@bcmills @jayconrod I'm encountering this issue again with go get -d on Go 1.16.4, so I'm a bit confused:

$ go version
go version go1.16.4 linux/amd64
$ go get -d mvdan.cc/sh/v3@v3.2.0 # no "+build gofuzz" file
go: downloading mvdan.cc/sh/v3 v3.2.0
$ go get -d mvdan.cc/sh/v3@v3.3.0 # "+build gofuzz" file appears here
mvdan.cc/sh/v3: no Go source files

Edit: I should note that go version devel go1.17-ce92a2023c Sat May 15 02:39:08 2021 +0000 linux/amd64 works fine there.

@mvdan, interesting! I see the same behavior with go1.16.4 but not with gotip:

$ go version
go version devel go1.17-8b0901fd3 Tue May 18 07:50:25 2021 +0000 linux/amd64

$ go get -d mvdan.cc/sh/v3@v3.3.0
go: downloading mvdan.cc/sh/v3 v3.3.0
go get: added mvdan.cc/sh/v3 v3.3.0

$ go1.16.4 get -d mvdan.cc/sh/v3@v3.3.0
mvdan.cc/sh/v3: no Go source files

$

So we must have fixed something else during the 1.17 cycle, but I'm not sure what.

Should we reopen this temporarily while we investigate, or open a new issue about it? I'll tend to forget about these things if they're buried in a closed issue :)

Since this doesn't reproduce at head, I'd say no: I don't think we would backport a fix even if we found it, given that it's fairly easy to work around. (You can go get -d the specific package(s) you need instead of the module root.)

(If it were a regression from 1.15 to 1.16 that would be another matter, but the situation was even worse on 1.15... 😅)

Fair enough, I'll add a workaround on my end for now - since I do think it's reasonable to go get -d module-path, and I do it pretty often :)