-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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: load $GOROOT/go.env before loading user go.env #57179
Comments
naming it |
They could come to that wrong conclusion with any filename, I think :) Even with I personally think proper docs would be enough. This would realistically only appear in downstream Go distributions and packages, and in general, users wouldn't go look inside GOROOT directly. |
Perhaps we should accept a go.env in the work module or next to go.work as well. There have been various issues asking for per-module configuration in go.mod. Go.mod is not the right place for that, which is why those were declined, but if we already have the search order $GOROOT/go.env, $userconfigdir/go.env, it might make sense to insert $workdir/go.env between them, where $workdir is the directory containing the go.work (if any) or else the one containing the work module's go.mod. Of course, go.env would only apply in the work module and would be ignored in dependencies. There are security concerns to think through for people who clone other repos and then open them in editors. We'd also have to decide what GOENV means and especially what GOENV=off means. This would address:
In #57001, there is some complication due to having both the |
This proposal has been added to the active column of the proposals project |
The reactions here are uniformly positive. Does anyone object to accepting this proposal? |
Hi Russ, minor clarification -- is a module/workspace go.env as described above in #57179 (comment) currently considered part of this proposal, or is that just a possible future extension? |
I think the work module go.env #57179 (comment) should be a separate proposal. Introducing
|
Thanks @hyangah. I started answering these questions but there are too many significant problems with the per-module go.env that don't arise with the $GOROOT/go.env. Let's keep this proposal scoped to just the $GOROOT/go.env. The $GOROOT/go.env source is an alternative to editing the source code to change the hard-coded defaults, so that's less of a change. |
Marking this likely accept but only for $GOROOT/go.env, not a per-module go.env. |
Based on the discussion above, this proposal seems like a likely accept. |
Change https://go.dev/cl/462198 mentions this issue: |
I confused myself and submitted this before it was accepted. Reopening. |
No change in consensus, so accepted. 🎉 |
Done. |
Is there a write-up of the issues with a per-module or per-workspace go.env? That seems like it would be helpful in Kubernetes, especially once we adopt go workspaces fully. Our need for wrapper scripts will approach zero. |
What if the source repository had logic that looked (roughly) like this:
With With |
* New upstream release. * Include temporary fix for default environment variables[0]. [0]: golang/go#57179
fix build error: "GOPROXY list is not the empty string, but contains no entries" see: golang/go#57179
I've been looking at the patches that distributions apply to Go. We'd like to remove as many as possible, so that once reproducible builds land (#24904, #57007), Linux distributions that rebuild from source should still be shipping the identical binaries that are distributed on https://go.dev/dl.
Debian patches are here: https://sources.debian.org/patches/golang-1.15/1.15.15-1~deb11u4/
Fedora patches are here: https://src.fedoraproject.org/rpms/golang/tree/rawhide
Debian's are all test changes. Fedora has one non-test change in cmd/link that maybe we should pick up if gcc has been fixed. Fedora also changes the default values for GOPROXY and GOSUMDB. Setting aside the fact that they are opening their users to supply chain attacks, it would be good if they didn't have to modify the binaries to do it. We also expect over on #57001 that Fedora will want to default GOTOOLCHAIN=local, and perhaps Debian will too.
Today the default Go environment variables are modified using 'go env -w' which writes to filepath.Join(os.UserConfigDir(), "go/env"). On my Mac that's
$HOME/Library/Application Support/go/env
. On Linux that's$HOME/.config/go/env
.I propose that when the go command loads that file, it first loads $GOROOT/go.env and then the user file. Any setting in the user file overwrites an equivalent setting in the $GOROOT/go.env, and the environment overwrites both (as always).
Then distributions that want to modify the defaults do not need to edit source code and create non-standard binaries. They can just write a $GOROOT/go.env.
The text was updated successfully, but these errors were encountered: