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: unable to run go commands from within another GOROOT #30756

Closed
josharian opened this issue Mar 12, 2019 · 4 comments

Comments

Projects
None yet
3 participants
@josharian
Copy link
Contributor

commented Mar 12, 2019

First off: This is a weird issue. I acknowledge that. But it messes with my personal workflow, so I'm curious whether it can be satisfactorily resolved.

Reproduce:

  • Clone toolchain to .../a; run .../a/make.bash
  • Ditto in .../b
  • cd .../b/src
  • Execute .../a/bin/go test bytes

Result:

go: reserved module path std not allow outside of GOROOT/src

There are three things going on here:

  • Grammatical error in error message.
  • Mysterious error message; it took me a while to realize the problem.
  • I don't see why this no longer works. Why must this be an error?

For context: When working on the compiler, I generally hang out in GOROOT/src. I use compilecmp to generate built toolchains with different versions. Then I refer to those versions by absolute path to run benchmarks.

This also sometimes happens under the hood. I already had to fix compilecmp because it could not be run from GOROOT/src because of the same issue.

It's an annoyance to have to cd around to run benchmarks, take care with what dir you're piping results to, etc.

cc @bcmills @jayconrod

@bcmills bcmills self-assigned this Mar 12, 2019

@bcmills

This comment has been minimized.

Copy link
Member

commented Mar 12, 2019

Execute .../a/bin/go test bytes

Do you mean .../a/bin/go test ./bytes, with a ./? Because otherwise I'm not sure how that would work in the first place: the name bytes would be ambiguous.

@josharian

This comment has been minimized.

Copy link
Contributor Author

commented Mar 12, 2019

Because otherwise I'm not sure how that would work in the first place: the name bytes would be ambiguous.

Without a ./. Why is it ambiguous? It always used to work; it refers to the bytes in the GOROOT of the go command being executed.

@bcmills

This comment has been minimized.

Copy link
Member

commented Mar 12, 2019

Ah, I see what you mean.

If we have the invariant that the module std always refers to the standard library (and that its packages therefore always lack a prefix), then it's ambiguous because we don't know whether bytes refers to the std module in GOROOT, or to the std library in the current working directory.

On the other hand, if we treat a std module outside of GOROOT as just another module, perhaps that isn't a problem. (But it does mean that your workflow will break again if there is ever a standard subtree beginning with std/.)

@gopherbot

This comment has been minimized.

Copy link

commented Mar 12, 2019

Change https://golang.org/cl/167080 mentions this issue: cmd/go/internal/modload: treat a 'std' module outside GOROOT/src as an ordinary module

@bcmills bcmills added the NeedsFix label Mar 12, 2019

@bcmills bcmills added this to the Go1.13 milestone Mar 12, 2019

@bcmills bcmills added the modules label Mar 12, 2019

@gopherbot gopherbot closed this in f54b890 Mar 12, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.