cmd/go: "package … is not in GOROOT" is confusing in module mode when the package would exist in GOPATH mode

[notzippy]

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

$ go version
go version go1.14.2 linux/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output

$ go env

What did you do?

If a parent folder contained a go.mod this overrides the GOPATH setting and there is no clear indication this is happening.
lets say the following exists in the file system

/work/go.mod 

and say you create a folder like

/work/projects/x/src/my/test2/main.go

and you export the GOPATH to point to your project

export GOPATH=/work/projects/x/

You will get an error like

can't load package: package my/test2 is not in GOROOT (/home/me/.gvm/gos/go1.14.2/src/my/test2)

And much time and head bashing will occur because you dont realize that go is using the /work/go.mod and overrides your GOPATH that you defined. This behavior is different then go 1.12 as well (it compiles without issue) so that adds to the confusion. (To be fair... I am totally guilty as sin for my own nasty creation, but there should be a better way of pointing out the root cause.)

What did you expect to see?

It would be great to see some reference to the go.mod file in the error message and not the GOROOT.

can't load package: package my/test2 is not in GOROOT (/home/me/.gvm/gos/go1.14.2/src/my/test2) with (/work/go.mod)

Or even more directly

can't load package: package my/test2 is not in go.mod (/work/my/test2)

I agree the former error is not wrong, but it is pointing in the wrong direction

What did you see instead?

can't load package: package my/test2 is not in GOROOT (/home/me/.gvm/gos/go1.14.2/src/my/test2)

[bcmills]

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.)

[bcmills]

CC @matloob @jayconrod

[bcmills]

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.

[jayconrod]

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.

[bcmills]

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! 😅

[ahhzaky]

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

[blizardinka]

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".

[yyccQQu]

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

[ianlancetaylor]

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

[ianlancetaylor]

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

[ghost]

Type these two commands in your terminal to resolve the issue

go env -w GO111MODULE=off

set GOPATH=D:\go

[perqueza72]

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?

[ivackerdev]

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

[ianlancetaylor]

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

[10035]

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

[earthaYan]

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?

[ljfreelancer88]

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

[angelomao]

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!

[quantonganh]

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?

[gopherbot]

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

[bcmills]

@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.