Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
notzippy opened this issue May 2, 2020 · 16 comments
Labels
help wanted modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@notzippy
Copy link

notzippy commented May 2, 2020

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
Copy link
Member

bcmills commented May 4, 2020

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
Copy link
Member

bcmills commented May 4, 2020

CC @matloob @jayconrod

@bcmills bcmills added this to the Unplanned milestone May 4, 2020
@bcmills bcmills changed the title More meaningful message then package is not in GOROOT cmd/go: "package … is not in GOROOT" is confusing in module mode when the package would exist in GOPATH mode May 4, 2020
@bcmills bcmills added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label May 4, 2020
@bcmills bcmills modified the milestones: Unplanned, Backlog May 4, 2020
@bcmills bcmills added the modules label May 4, 2020
@bcmills
Copy link
Member

bcmills commented May 4, 2020

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
Copy link
Contributor

jayconrod commented May 4, 2020

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
Copy link
Member

bcmills commented May 4, 2020

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
Copy link

ahhzaky commented Sep 17, 2020

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

@blizardinka
Copy link

blizardinka commented Jan 1, 2021

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

@bcmills bcmills self-assigned this Jun 24, 2021
@bcmills bcmills modified the milestones: Backlog, Go1.18 Jun 24, 2021
@yyccQQu
Copy link

yyccQQu commented Aug 23, 2021

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
Copy link
Contributor

ianlancetaylor commented Nov 16, 2021

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

@ianlancetaylor
Copy link
Contributor

ianlancetaylor commented Jan 28, 2022

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

@ghost
Copy link

ghost commented Jan 29, 2022

Type these two commands in your terminal to resolve the issue

go env -w GO111MODULE=off

set GOPATH=D:\go

@perqueza72
Copy link

perqueza72 commented Feb 1, 2022

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?

@bcmills bcmills modified the milestones: Go1.18, Go1.19 Feb 1, 2022
@ivackerdev
Copy link

ivackerdev commented Mar 22, 2022

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

@ianlancetaylor
Copy link
Contributor

ianlancetaylor commented Jun 24, 2022

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

@bcmills bcmills modified the milestones: Go1.19, Backlog Jul 14, 2022
@bcmills bcmills removed their assignment Jul 14, 2022
@10035
Copy link

10035 commented Sep 16, 2022

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
Copy link

earthaYan commented Oct 8, 2022

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
Status: No status
Development

No branches or pull requests