buildGoModule: pass GOFLAGS with env and construct from goFlags

[ShamrockLee]

Pass GOFLAGS as env.GOFLAGS to support __structuredAttrs = true.

Introduce a new argument, goFlags, to form GOFLAGS at evaluation time. (Environment variables passed via env cannot be a list.)

This PR depends on #359641. Once the dependent PR is merged, I'll rebase this feature branch and drop the [placeholder] commit.

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.

[TomaSajt]

I'm not sure if we should do this from nix.

Can't we perhaps have goFlags be used as a bash array and set GOFLAGS later in bash?

[ShamrockLee]

I am thinking about it. Operating on goFlags and forming GOFLAGS as needed makes the interface more consistent.

Still, as GOFLAGS acts as the "default flags for all Go commands if applicable," people are likely to expect GOFLAGS to be defined before the first execution of the go command. Defining and exporting GOFLAGS in one of the prePhases seems to defeat the purpose of making goFlags modifiable after evaluation.

[TomaSajt]

By the way, is the rationale behind having goFlags the fact that lists are more ergonomic to use with overrideAttrs?

[ShamrockLee]

By the way, is the rationale behind having goFlags the fact that lists are more ergonomic to use with overrideAttrs?

It's because a list is more structured than a string, and I hope to keep having a way to specify GOFLAGS with a list. As you said, the main benefit would be a smoother overrideAttrs experience.