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
proposal: runtime: deprecate GOROOT() function #51473
Comments
I think this is an interesting proposal, and I agree with the current confusion causing problems at times. I assume that, if a program wants to try both approaches, they could have code that first tries one approach (like |
I fully agree with your suggestion to use So when it comes to |
One possible solution would be to add a private flag to Lines 1182 to 1188 in 81767e2
|
Would that help with the added init cost, though, if its init func may still call |
@mvdan I'm not suggesting that the init func for go/build call Alternatively, at the top of |
Ah, I see. I was thinking mainly of end users directly reading |
The one case I can think of where At least in principle, it is possible for the |
@bcmills I'm not sure what the use cases are for looking up |
That's true, but if you compile a test binary with Even so, I suspect that most tests that depend on |
Gotcha. Actually, as an optimization, since we know that I guess another approach would be to have |
This proposal has been added to the active column of the proposals project |
@bradfitz reports that he has uses of runtime.GOROOT in GitHub actions where built binaries want to find the toolchain that built them, so they can invoke it to do other things. It seems like we probably need to enumerate the uses people have for runtime.GOROOT and what they should do instead. It doesn't help to just say "Deprecated". We have to say what to use instead. |
For example:
|
@bradfitz I'm not sure which repos those are, but this seems to at least partially align with with what @bcmills mentioned above re: tests. In that situation, we can make With regards to non-test binaries that intend to find the toolchain that built them, this feels somewhat ill-defined, for the reasons mentioned above, as well as issues with In short:
|
@bradfitz, thanks for those examples. I cloned the (They happen to pass when run with
There is also no guarantee in general that even a non-empty That's of course fine for tailscale's own code if you're ok with those failure modes, but may be further evidence that we should discourage that pattern in general. A more robust approach might be to simply look for |
Is "finding the go command" the only thing we need GOROOT for? Probably? Possibilities:
Number 3 would fit well with non-test code like go/build and go/packages that already assume that looking for "go" in your PATH is the one you want. Thoughts on finding the go command? And thoughts on any other needs from GOROOT? |
That wouldn't necessarily even require a new environment variable: a flag might suffice. I think the API is the tricky part. Maybe: package testing
// GOROOT reports the GOROOT with which the test was built, if known.
// This function may report a non-empty GOROOT even if runtime.GOROOT
// returns the empty string (such as if the test was built with -trimpath).
func GOROOT() (string, bool) |
Having I think this option is not really much better than deciding not to deprecate |
I like that approach a lot overall. It looks like That would also make it fairly trivial to identify the |
It sounds like people like "Have 'go test' put the Go bin directory at the front of $PATH before running the test binary." so let's start with that. @bcmills, want to write a CL for that? Then tests and things like go/packages that exec "go" will work fine without runtime.GOROOT. At that point, what is left for use cases for runtime.GOROOT? |
@rsc making sure I understand your last response: would |
@danderson, the |
Are there any other problems with deprecating runtime.GOROOT, once we've guaranteed that "go in the PATH" is the right go during a test? |
Change https://go.dev/cl/404134 mentions this issue: |
https://go.dev/cl/404134 contains the suggested change to |
It sounds like CL 404134 will be in Go 1.19. Let's see how that goes and circle back to this. |
Placed on hold. |
…d 'go test' This causes tests and generators that execute 'go' as a subprocess to use the same go command as the parent 'go test' or 'go generate' command. For #51473. Change-Id: I003cf1d05d1c93a26c6a7fdfad25e86c11765f59 Reviewed-on: https://go-review.googlesource.com/c/go/+/404134 Run-TryBot: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Bryan Mills <bcmills@google.com> Reviewed-by: Russ Cox <rsc@golang.org>
Change https://go.dev/cl/409176 mentions this issue: |
I think this is also affecting With
While Changing the PATH env for the |
@seankhliao, I think it's more intuitive for
(That said, |
For #51473. Change-Id: I01a35e5ebc83b8b72e414ed1730e9147ea590959 Reviewed-on: https://go-review.googlesource.com/c/go/+/409176 Reviewed-by: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Bryan Mills <bcmills@google.com> Auto-Submit: Bryan Mills <bcmills@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Change https://go.dev/cl/450714 mentions this issue: |
The 'cgo' command invoked by 'go fix' was not valid when built with -trimpath, but the test was not failing because errors from the command were being logged and ignored instead of causing tests to fail. Changing the code and test not to ignore the errors revealed that a number of existing tests were always, unconditionally triggering cgo errors which were then ignored. This change updates those tests to no longer produce cgo errors, and to check their results when cgo is enabled. For #51473. Updates #51461. Change-Id: Ib9d1ea93f26d30daa824d75ed634eaf530af086d Reviewed-on: https://go-review.googlesource.com/c/go/+/450714 Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Bryan Mills <bcmills@google.com> Auto-Submit: Bryan Mills <bcmills@google.com>
@bcmills your change for Go 1.19 is great. I was able to delete some code that tried to figure out the right Could we document it as part of |
The
runtime.GOROOT()
function is currently implemented as follows:GOROOT
environment variable is set, return its value.Unfortunately, this implementation cannot be relied upon to have any semantic meaning in general.
If the intent is to know what GOROOT the binary was compiled with, then consulting the
GOROOT
environment variable is wrong. Instead, the burned in value should be added todebug.BuildInfo
.If the intent is to know the GOROOT on the current machine, then consulting the burned in value is wrong, as it cannot handle the following (non-exhaustive) scenarios:
GOROOT
.PATH
environment variable may have changed since the binary was compiled.Instead, the
go env GOROOT
command should be used. In particular, this change needs to be made forgo/build.Default
to function properly in all cases.The text was updated successfully, but these errors were encountered: