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 · 5 comments

Comments

@notzippy
Copy link

@notzippy 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 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 bcmills commented May 4, 2020

@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 modified the milestones: Unplanned, Backlog May 4, 2020
@bcmills bcmills added the modules label May 4, 2020
@bcmills
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.