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

Jump to bottom

cmd/go: unable to run go commands from within another GOROOT #30756

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

cmd/go: unable to run go commands from within another GOROOT #30756

josharian opened this issue Mar 12, 2019 · 4 comments
Labels
FrozenDueToAge modules NeedsFix The path to resolution is known, but the work has not been done.
Milestone
Go1.13

Comments

@josharian
Copy link
Contributor

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

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

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

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

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 The path to resolution is known, but the work has not been done. label Mar 12, 2019
@bcmills bcmills added this to the Go1.13 milestone Mar 12, 2019
@bcmills bcmills mentioned this issue Jul 18, 2019
Open
@golang golang locked and limited conversation to collaborators Mar 11, 2020
@rsc rsc unassigned bcmills Jun 23, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge modules NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Milestone
Go1.13
Development

No branches or pull requests
3 participants
@josharian @bcmills @gopherbot