proposal: cmd/go: add go env -w to set default env vars

[rsc]

Setting environment variables for go command configuration
is too difficult and system-specific.
We propose to add go env -w, to set defaults more easily.

See https://golang.org/design/30411-env.

(Note: When this was just a placeholder issue to get a number allocated for the design doc, the text here said only "mine all mine". The laughing emoji reactions are from that original text.)

[gopherbot]

Change https://golang.org/cl/164817 mentions this issue: design: add 30411-env.md

[mvdan]

(The "laugh" emojis were for the original "mine all mine" content)

Is there a reason why this has become relevant all of a sudden? I have seen a few junior developers have issues with environment variables, but I don't think the issue is severe enough to warrant adding the first per-user Go config file.

[josharian]

Two comments about fine details:

If the file contains multiple lines beginning with =, only the first has any effect.

May I suggest that later values override earlier? That’s how env vars work (see os/exec’s handling of duplicate env vars), and the implementation is clearer.

Lines with empty values set the default value to the empty string, possibly overriding a non-empty default.

I’d suggest omitting the second half of this sentence. When I first read it, in part due to context, I thought it was an exception to the “first entries” sentence immediately preceding it.

[josharian]

I don't think the issue is severe enough to warrant adding the first per-user Go config file.

FWIW, yesterday I was struggling with a Windows gomote. I am unfamiliar with windows and had to search for how to set env vars. And then was frustrated every time my ssh connection dropped, because I had to re-set my env vars. This proposal would have made my life considerably more pleasant.

[rsc]

@josharian, really duplicates should not happen, so this shouldn't matter at all, but it needs to be well-defined. The implementation of 'first wins' is quite clear: read the file until you get to the line you want, and stop. Yes, there's a clear implementation for 'last wins' too, but first seems like what most people would do when reading the file.

[rsc]

@mvdan, like the proverbial boiling frog, this has been bothering me for quite a while. It's not just junior developers. I personally have a hard time setting default environment variables. We've made go work very well out of the box but at the same time it's not uncommon to need to change a default here or there, and it's honestly just too hard. In Go 1.13 we expect to set a default GOPROXY, and we want to make sure it's easy to modify that setting. But really GOPROXY is just the latest of many straws, and the camel's back is already broken.

[josharian]

first seems like what most people would do when reading the file.

It’s not what I would do. :P I’ll take one more stab at this, and then let it drop. (I agree that either way it is not particularly critical.)

go env produces output that can be piped to a shell...in which case later overrides earlier. go env -w strikes me as having output that gets piped indirectly to a shell. So I would expect similar behavior.

[mvdan]

I agree with Josh that if the file should generally not have duplicates, it should follow the same logic as the env command and os/exec :) That's what most people would expect anyway, I think.

The reason I was asking about the urgency of this change for 1.13 was because I presumed that Go could be used by new developers without setting any env vars. Windows is a good point, I have to admit I don't know how to set an env var, though I hope I won't need to. The timing makes a lot more sense given your point about GOPROXY.

A way to summarize my concern with this proposal is that, right now, Go's behavior only changes via env vars and via PWD (modules). Adding a per-user config file adds another dimension to the problem, and I could imagine that resulting in confusion. Perhaps less confusion than setting env vars in a portable way, but still unfortunate.

[rsc]

@josharian, go env -w will never write a file with duplicate values. If a variable appears multiple times on the command line, that can just be an error.