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: add a way to query for non-defaults in the env #34208
Comments
This got no attention, so I'm rewriting it into a proposal. |
I think this is a good idea, both because it helps us and because it might help the user with "bugs" that are really misconfigurations. Would it make sense to simply enhance the existing output with a trailing shell comment for the modified ones, that way it still copy-pastes as environment variable settings? E.g.
|
That would work for me too. Though that might be a little too close to shell syntax for people's comfort :) I also wonder if backwards compatibility would be a problem. For example, |
We briefly discussed this in today's tools call. @jayconrod mentioned comments, but I'm still a bit worried about those in case anyone is expecting simple Another idea that came out during the call would be extending
cc @bcmills |
what about explaining where each value comes from?
|
I see why this could possibly be useful but it's also a giant pain. I am not sure the benefit is worth the effort. |
Does someone want to prototype this to see if there is a simple implementation? |
This proposal has been added to the active column of the proposals project |
Placed on hold. |
I have been working on one. The proposal has been placed on hold though. Are there any further details that can be shared about that? |
We place proposals on hold if we think they may be valuable but want more information before committing to a decision. In this case we'd like to see an implementation and its effect on |
DO NOT SUBMIT Fixes golang#34208 Change-Id: Ia836aae7176aee926fe47b09fad28d265f8e0404
I wrote a prototype for this proposal that will work well on my computer.
|
Change https://go.dev/cl/563137 mentions this issue: |
@seankhliao, I think a flag for the source of the setting would be useful (like An interesting related question, though, is: what should |
This proposal has been added to the active column of the proposals project |
I think go env -changed only prints the non-default values of the environment variables that go env will print.
See #34208 (comment)
If print blank line, Once the go env -changed is use in the future in https://github.com/golang/go/issues/new?assignees=&labels=&projects=&template=00-bug.yml&title=import%2Fpath%3A+issue+title |
The question is what happens with 'go env -changed GOPATH GOROOT GOMODCACHE' for example.
In this case, GOROOT is arguably unchanged, as is GOMODCACHE; but GOPATH is changed. So is this what it prints?
If so, how do you know which of the three values got printed? This is why @bcmills recommended the blank line, which makes sense to me:
Only programs are likely to use this anyway, and they can read the blank lines well enough. The usage of go env in issues would be unaffected: we all agree that plain |
my machine in windows
in wsl2
Because the print format can always be name=value, so I don't think I need to print empty lines. |
DO NOT SUBMIT Fixes golang#34208 Change-Id: Ia836aae7176aee926fe47b09fad28d265f8e0404
OK, this seems fine. |
Have all remaining concerns about this proposal been addressed? The proposal is to add a new flag to go env: ‘go env -changed’. With no other flags or arguments, ‘go env -changed’ prints all non-default settings When there are command-line arguments, as in ‘go env -changed X Y Z’, the command behaves exactly like ‘go env -changed’ except it limits the consideration to X, Y, and Z. It still omits default settings. This output has a different form from ‘go env X Y Z’ in that it includes the ‘key=’ prefixes (or ‘set key=’ on Windows). When using ‘go env -json -changed’, the JSON only includes the changed values. ‘go env -json -changed X Y Z’, similarly limits the consideration to X, Y, and Z. |
Based on the discussion above, this proposal seems like a likely accept. The proposal is to add a new flag to go env: ‘go env -changed’. With no other flags or arguments, ‘go env -changed’ prints all non-default settings When there are command-line arguments, as in ‘go env -changed X Y Z’, the command behaves exactly like ‘go env -changed’ except it limits the consideration to X, Y, and Z. It still omits default settings. This output has a different form from ‘go env X Y Z’ in that it includes the ‘key=’ prefixes (or ‘set key=’ on Windows). When using ‘go env -json -changed’, the JSON only includes the changed values. ‘go env -json -changed X Y Z’, similarly limits the consideration to X, Y, and Z. |
I think this would solve the problem I was having here as well where I didn't realize i was setting an empty string which was different than the default. |
No change in consensus, so accepted. 🎉 The proposal is to add a new flag to go env: ‘go env -changed’. With no other flags or arguments, ‘go env -changed’ prints all non-default settings When there are command-line arguments, as in ‘go env -changed X Y Z’, the command behaves exactly like ‘go env -changed’ except it limits the consideration to X, Y, and Z. It still omits default settings. This output has a different form from ‘go env X Y Z’ in that it includes the ‘key=’ prefixes (or ‘set key=’ on Windows). When using ‘go env -json -changed’, the JSON only includes the changed values. ‘go env -json -changed X Y Z’, similarly limits the consideration to X, Y, and Z. |
DO NOT SUBMIT Fixes golang#34208 Change-Id: Ia836aae7176aee926fe47b09fad28d265f8e0404
It's common to ask users to provide
go version
andgo env
when they report a bug. There is one problem with that, though - the output is getting huge, and most of it is generally useless. For example:What's special about my environment? You can easily spot
GO111MODULE
orGOBIN
as they are commonly set, and they are near the top. But what variables have I actually modified from the defaults on my system?It would be useful to quickly see what Go env variables were specifically modified by a user. That is, what could be special about the user's environment, that could help in reproducing a bug they're running into.
I can kind of get that right now with a bit of shell hackery, showing the changes between my
go env
and the samego env
with an empty environment:This is much better. It even has some surprises - I botched my
GOPROXY
by forgetting,direct
, for example. And I'm not sure whyGOGCCFLAGS
is different.GONOPROXY
andGONOSUMDB
are also a bit redundant as they simply followGOPRIVATE
here, but that's a minor thing.It would be useful to be able to print a summary like the above, perhaps with
go env -diff
orgo env -changed
. Note that the idea is to show what's different from the defaults on that machine, so usuallyGOARCH
andGOOS
wouldn't be included.The text was updated successfully, but these errors were encountered: