buildGoModule: Use the env attribute to pass environment variables

[ShamrockLee]

Pass all environment variables with env and instruct users to do so in the Nixpkgs Reference Manual.

This is part of the efforts to allow buildGoModule to take __structuredAttrs = true. This change would only rebuild the documentation and is easy to merge (it turns out to be a tree-wide fix, but fortunately, reviewers can reproduce the tree-wide changes by string substitution). Other significant/mass-rebuilding changes are split away to make reviewing smoother.

One may notice that the added code's indentation differs from the surrounding code. That is because the original code is out-of-formatting and indented too much.

These changes should rebuild no packages other than the documentation.

Cc:
@doronbehar @kalbasit @zowoq (people who might be interested in buildGoModule)
@emilazy @wolfgangwalther (people who might be interested in __structuredAttrs)

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[ShamrockLee]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 359641

---

x86_64-linux

⏩ 1 package blacklisted:

• nixos-install-tools

✅ 2 packages built:

• nixpkgs-manual
• promtail

[emilazy]

Does it maybe make sense to keep CGO_ENABLED as part of the interface here like GOFLAGS, just because it’s so ubiquitous? (No strong opinion here, just wondering. Isn’t GOFLAGS also just an environment variable ultimately?)

Edit: Ah, I see you have plans for GOFLAGS too, okay :)

[ShamrockLee]

Does it maybe make sense to keep CGO_ENABLED as part of the interface here like GOFLAGS, just because it’s so ubiquitous?

It would be easier for now, as you are suggesting.

Still, if we plan to convert build helpers to support fixed-point attributes (finalAttrs: { ... }) like stdenv.mkDerivation does, the fewer removeAttrs the better. (Build helpers without removeAttrs can use overrideAttrs to achieve out-of-the-box conversion without waiting for #234651.)

[ShamrockLee]

Edit: Ah, I see you have plans for GOFLAGS too, okay :)

#359744 is the plan.

[ShamrockLee]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 359641

---

x86_64-linux

⏩ 1 package blacklisted:

• nixos-install-tools

✅ 1 package built:

• nixpkgs-manual

[kalbasit]

Thanks @ShamrockLee

[doronbehar]

Changes to buildGoModule look pretty good to me. Haven't iterated the packages' specific commits, but I guess they are trivial and should be good to go.

[ShamrockLee]

Regarding the use of environment variables to control the Go compiler, the current implementation of this PR shadows env.GO111MODULES, env.GOTOOLCHAIN, env.GOOS, and env.GOARCH, as the previous buildGoModule implementation did to the directly-specified version of these arguments.

Should we respect users' specifications for all these variables via env or keep shadowing them silently?

[ShamrockLee]

Rebased and resolved merge conflicts with #359798.

[TomaSajt]

Is there a plan to also move GOFLAGS in the future?
Currently, the nix logic adds additional values to GOFLAGS, but that could also be done from bash as well.
I did it like this:

nixpkgs/pkgs/build-support/go/build-hook.sh

Lines 6 to 20 in 9273a74

	export GOFLAGS
	# currently pie is only enabled by default in pkgsMusl
	# this will respect the `hardening{Disable,Enable}` flags if set
	if [[ $NIX_HARDENING_ENABLE =~ "pie" ]]; then
	prependToVar GOFLAGS "-buildmode=pie"
	fi
	if [ -z "${allowGoReference-}" ]; then
	appendToVar GOFLAGS "-trimpath"
	fi
	if [ -z "${proxyVendor-}" ]; then
	appendToVar GOFLAGS "-mod=vendor"
	fi

(This doesn't handle the current nix-side GOFLAGS validation warnIfs)

---

(I don't have a lot of experience with different variable types in bash, so I might have some misconceptions.)

[ShamrockLee]

Is there a plan to also move GOFLAGS in the future?

It's #359744.

The [placeholder] commit puts only the GOFLAGS and not other environment variables under env = {...} as a proof of concept. Once this PR is merged, I'll rebase #359744, dropping the [placeholder] ... commit and put GOFLAGS into env = { ... } together with other environment variables.