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

$ go version
go version devel go1.20-6fc1f4f906 Fri Nov 18 20:22:20 2022 +0000

Does this issue reproduce with the latest release?

Yes, tip and 1.19.

What did you do?

Build a package with a bad dotless import, such as (link):

package treesort

import (
	"fmt"
	"treesort"

	"something.com/something"
)

func f() {
	fmt.Println(treesort.Foo)
	fmt.Println(something.Bar)
}

What did you see?

An error mentioning GOROOT:

prog.go:5:2: package treesort is not in GOROOT (<path>/sdk/gotip/src/treesort)
prog.go:7:2: no required module provides package something.com/something; to add it:
        go get something.com/something

That particular example is a package importing itself with a dotless import path, but you get a similar error if for example you remove the "treesort" import and remove the .com from the "something.com/something" import (link):

prog.go:5:2: package something/something is not in GOROOT (/usr/local/go-faketime/src/something/something)

What did you hope to see?

An error that does not mention GOROOT. I've seen multiple instances where the mention of GOROOT is a red herring that can send someone in the wrong direction, especially if they are new to Go, and they can start asking questions like "Where is GOROOT set?" (e.g., recent golang-nuts thread).

In that example thread, Ian remarked:

In general you should never set GOROOT. It's a special purpose hook that is almost never needed.

It might help to avoid mentioning GOROOT at least in that particular error message, including because someone newer to Go or newer to modules is more likely to get a dotless import wrong and then not know how to resolve it.

Without getting into exact wording just yet:

1. For the general case of a bad dotless import, perhaps the message could communicate that for example something/something is not a package in the standard library and was not found in a dependency in go.mod (and maybe go.work, if there is one), or something along those lines.

2. For more specific example of the treesort package, perhaps cmd/go could explicitly call out that a package is trying to import itself.

If there is interest in changing this, I'd be happy to send a CL. If anyone has a suggestion on exact wording, please feel free to leave a comment.

cmd/go of course already knows about the standard library and GOROOT. For example, these current error messages mention the standard library and avoid mention of GOROOT:

mod_install_pkg_version.txt:stderr '^go: fmt@v1.0.0: argument must not be a package in the standard library$'

mod_upgrade_patch.txt:stderr 'go: can''t request explicit version "patch" of standard library package cmd/vet$'

Related (with an additional specific case): #38812