WIP: experiment with a hook based alternative to buildGoModule

[TomaSajt]

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/)
• 24.11 Release Notes (or backporting 23.11 and 24.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.

[jian-lin]

I guess the motivation of this PR is to increase composability, meaning constructing one call to stdenv.mkDerivation with functionalities provided by more than one build helpers, such as buildGoModule and rustPlatform.buildRustPackage.

Would it be more composable if we also add goBuildHook (with runHook removed, of course) to preBuildHooks or postBuildHooks?

Use case: one package, with its own buildPhase, wants to build some go stuff.

Here is my implementation of this idea for Rust: #334476.

[katexochen]

I like the idea of moving to a hook based alternative, but I think it will need some discussion on how exactly such a future builder would look like. Maybe you can make your experiment consumable via an out-of-tree flake for now, so people can evaluate and test it? This is what was done for gomod2nix (which didn't end up in nixpkgs in the end).
Also, notice there is another hook-based experiment in https://github.com/adisbladis/gobuild.nix. :)

[ShamrockLee]

IIRC, Bash doesn't support nested function declaration. Let's flatten the definition of these Bash functions.

[ShamrockLee]

Suggested change

	goBuildHook() {
	goBuildPhase() {

AFAICT, fooBarHook is meant to be run when doing runHook foo.

Also, I would propose also defining goBuild, which runs all the goBuildPhase commands except runHook preBuild and runHook postBuild. This way, goBuild could be inserted into the pre- and post-phases of other build helpers/workflows. For example, apptainer uses the stdenv.mkDerivation's Make-based workflow during configuration and build but still requires the Go modules realization from goConfigurePhase. If we have goConfigure, we could plug it into preConfigure and switch on dontGoConfigure and dontGoBuild.