The package path my/test2 is not one that would normally be resolved from the go.mod file: since the path does not start with a hostname, absent a replace directive it normally could only be found as a package in the Go standard library, which it is not.

Note that the location of the go.mod file is already reported by go env. (And please fill out the complete issue template next time: the output of go env is often relevant.)

CC @matloob @jayconrod

Perhaps there is something we could do based on the fact that the package would exist if it were loaded in GOPATH mode, but I'm not sure exactly how we would phrase that.

There are a couple checks for go.mod files in unusual places ($GOPATH/go.mod, $TMP/go.mod). I guess that could be broadened: it would be an error if there's a go.mod file in any parent directory of $GOPATH.

Seems pretty broad though, and I expect it would break a lot of tool tests.

Seems pretty broad though, and I expect it would break a lot of tool tests.

Maybe? But tool tests in module mode need a go.mod file, which cannot be checked into the tree (because it would be a module boundary; see #27852), and cannot not be written into the existing testdata directory because it may not be writable (see #28387).

So if the check only happens in module mode, it should not actually affect any tests! 😅

why is my error like this "is not in GOROOT"? on windows10

Just check for correct imports in go files. External import file need to start with the module name, which u can find in go.mod under root dir. For example u have the structure like RootDir/main.go, RootDir/go.mod, RootDir/configs/constants.go and u want to import RootDir/configs/constants.go in RootDir/main.go. Check the name of module in go.mod. If there is "module example.com/RootDir, then yours import look like "import example.com/RootDir/configs" not like "RootDir/configs".

I had a similar problem
Delete the mod sum file
Make sure you do go mod init aaa in Terminal
Then be sure to go run main.go in terminal
Do not execute the corresponding command in the editor

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

@bcmils This is in the 1.18 milestone; time to move to 1.19?

Type these two commands in your terminal to resolve the issue

go env -w GO111MODULE=off

set GOPATH=D:\go

Type these two commands in your terminal to resolve the issue

go env -w GO111MODULE=off

set GOPATH=D:\go

In my case, the first command line resolve my problem. Thanks :).

Could you explain me what do that line?

Gracias, lo corregi con el comando: go env -w GO111MODULE=off

@bcmills @matloob This issue is marked for 1.19. It's just been rolling forward in milestones. Should it move to Backlog?

Had the same issue but it was due to not having the go module at root.

What I was trying to accomplish was to execute the commands in a Cobra CLI app

This is what I did to fix it:

go mod init root #created the go module
go mod tidy

in 1.19.1,I met this problem,and I solve it by keeping package name and corresponding folder name the same。But why can do like this?

Thank you for the hint! I've solved the issue by keeping the package name and corresponding folder name the same.

Type these two commands in your terminal to resolve the issue

go env -w GO111MODULE=off

set GOPATH=D:\go

Thanks for your workable approach which saves my day!

Perhaps there is something we could do based on the fact that the package would exist if it were loaded in GOPATH mode, but I'm not sure exactly how we would phrase that.

What do you think if we return something like this?

package my/test2 is not in std (/home/me/.gvm/gos/go1.14.2/src/my/test2)
found it in $GOPATH /work/projects/x/. Run in GOPATH mode by using GO111MODULE=off?

Change https://go.dev/cl/543275 mentions this issue: cmd/go: check if a package can be loaded in GOPATH mode

@quantonganh, the error should not suggest running in GOPATH mode because that is usually not the most appropriate solution.

Generally the best solution is to update the program and its dependencies to use modules with module-appropriate paths, and then use the go mod commands to manage them.