cmd/go: "no required module provides package" is confusing for paths under the current module

[mvdan]

Using https://pkg.go.dev/golang.org/x/tools/cmd/benchcmp as an example:

$ go version
go version devel +cf59850466 Wed Mar 10 09:01:05 2021 +0000 linux/amd64
$ cd tools
$ git checkout -q 44abc2a71b321b77c0a579d8c5bf2704d648c9e0
$ cd cmd/benchcmp
$ sed -i 's@benchmark/parse@missing/package@g' *.go
$ go build
benchcmp.go:15:2: no required module provides package golang.org/x/tools/missing/package; to add it:
    go get golang.org/x/tools/missing/package
$ go get golang.org/x/tools/missing/package
go get golang.org/x/tools/missing/package: no matching versions for query "upgrade"

What I do here is add an import to a missing package that could be part of the current main module. The example I use is perhaps silly, but it's somewhat common to end up in this situation. For example:

• Rebasing or applying an old patch that imports a package which is now moved or deleted
• Writing an import manually and making a typo

I get why the errors are technically correct. When I run go build, the go tool doesn't know if there happens to be a module with path golang.org/x/tools/missing or golang.org/x/tools/missing/package, which could possibly contain the package needed. And, when I run the go get, it finds no such module, and the main module can't be upgraded to contain such a package.

First, an assumption: nested Go modules are very rare, and should not be encouraged. So I don't think that we should be optimizing the error messages for that use case.

Now, some suggestions from the user's point of view, for this scenario:

1) The go build error shouldn't suggest go get. It's very unlikely that it will fix the problem. If the user really has nested modules that would be fixed with a go get, I imagine they know what they're doing and can figure out what to do.

For example, here's a suggestion:

$ go build
benchcmp.go:15:2: package golang.org/x/tools/missing/package does not exist in the main module

2) The go get error is confusing. For example, see what happens if I try to upgrade the main module:

$ go get -d golang.org/x/tools@latest
go get: can't request version "latest" of the main module (golang.org/x/tools)

Now, compare that with package paths:

$ go get -d golang.org/x/tools/foo/bar
go get golang.org/x/tools/foo/bar: no matching versions for query "upgrade"
$ go get -d golang.org/x/tools/foo/bar@latest
go get golang.org/x/tools/foo/bar@latest: no matching versions for query "latest"

If no nested module is found, I think it should just show the can't request version error, just like go get -d golang.org/x/tools@latest.

[jayconrod]

While the error message is technically correct (the package could be in another module with a longer path, and go get might add the correct requirement), it's far more likely that the package just doesn't exist. I agree that your proposed go build error message is better. The go get messages seem like they could be improved, too.

[gopherbot]

Change https://golang.org/cl/324470 mentions this issue: cmd/go: improve "invalid version" error messages

[bcmills]

Compare #33568.

[ianlancetaylor]

This is in the Go1.18 milestone. Is it likely to happen for 1.18? Thanks.

[ianlancetaylor]

@bcmills This is in the 1.18 milestone; time to move to 1.19? Thanks.

[ghost]

no required module provides package golang.org/x/w32

[iwdgo]

Issue seems solved. It is difficult to locate which commit but on go1.18 with the case filed, the message is more explicit. The reference to go get is replaced by the import causing the error (missing/path in this case).

GOPATH\golang\x\tools\cmd\benchcmp>go version
go version go1.18.1 windows/amd64

GOPATH\golang\x\tools\cmd\benchcmp>set GO111MODULE
GO111MODULE=off

GOPATH\golang\x\tools\cmd\benchcmp>go build
code in directory C:\Users\Costa\Documents\Google\golang\x\tools\cmd\benchcmp expects import "golang.org/x/tools/cmd
/benchcmp"
benchcmp.go:10:2: cannot find package "missing/path" in any of:
        C:\Program Files\Go\src\missing\path (from $GOROOT)
        C:\Users\Costa\Documents\Google\src\missing\path (from $GOPATH)

GOPATH\golang\x\tools\cmd\benchcmp>set GO111MODULE=

GOPATH\Google\golang\x\tools\cmd\benchcmp>go build
benchcmp.go:10:2: cannot find package "." in:
        C:\Users\Costa\Documents\Google\golang\x\tools\vendor\missing\path

GOPATH\golang\x\tools\cmd\benchcmp>

[lgandras]

Just wanted to add a comment to this. If your dependency looked like github.com/my-org/my-repo/missing/package You can get this as well if you have something like this in your go.work:

go 1.22.3

toolchain go1.22.5

use (
    ./my-repo
)

My local version wasn't updated and this was driving me nuts. All I had to do is git pull in my local copy of the referenced repo and the missing package started appearing. You'd never guess that from the error message.