goimports from gotools seems to depend on go at runtime in some cases.

[jaredmontoya]

Added go to goimports PATH

Here is the issue that lead to creation of this PR: numtide/treefmt-nix#318 (it has an example and reproduction instructions)

This was not the case before and if you know what exactly happened to goimports after an update and a better way to implement a fix let me know.

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.

[gabyx]

I actually asked in NixOs Matrix chat about this, and the consensus was that gotools cannot know the go version, thats why this PR is probably not ideal. But I am unsure as well. Otherwise it looks good.

[jaredmontoya]

I did not think of what can happen if go package is updated and goimports in gotools changes behavior, because nobody does when they use wrapProgram in other packages.

Any dependency added with wrapProgram to any package can be updated and change behavior of other programs that depend on it.

If someone can solve this problem upstream(in nixpkgs) better, I am all for it.
Suggestions to the PR are also welcome.

[gabyx]

Maybe @SuperSandro2000 knows more about it. I think it possible to override the runtime go package in this derivation if we need something else.

[SuperSandro2000]

goimports shouldn't care to much about the version but most other tools do and sometimes the diagnostics are even based on the available go.

[gabyx]

@SuperSandro2000 thanks, so then that PR is good to go. Thanks @jaredmontoya!