Unverified Commit a82c8611 authored by Doron Behar's avatar Doron Behar Committed by GitHub
Browse files

buildGoModule: don't inherit build hooks when building go-modules (#225349) 

* buildGoModule: don't inherit postBuild hook when building go-modules

This is a slight revert of 5ce647b8
(#212800).

Inheriting these hooks in the `.go-modules` derivation can be confusing:
One doesn't expect them to run when generating the fixed output modules
derivation, but only on the main derivation. A `postBuild` hook that
adds some files to $out will cause a very hard to debug issue[1].

This commit adds support for a dedicated `modPostBuild` hook that will
be used only by the derivation building `.go-modules`. Additionally,
`go.section.md` now explains these attributes behavior better.

[1]:
https://discourse.nixos.org/t/cant-update-a-go-package-getting-go-inconsistent-vendoring/27063/6



Co-authored-by: default avatarSandro <sandro.jaeckel@gmail.com>
parent e025c6f5

doc/languages-frameworks/go.section.md

+11 −1
Original line number Diff line number Diff line
@@ -20,6 +20,7 @@ In the following is an example expression using `buildGoModule`, the following a 


  To obtain the actual hash, set `vendorHash = lib.fakeSha256;` and run the build ([more details here](#sec-source-hashes)).

- `proxyVendor`: Fetches (go mod download) and proxies the vendor directory. This is useful if your code depends on c code and go mod tidy does not include the needed sources to build or if any dependency has case-insensitive conflicts which will produce platform dependant `vendorHash` checksums.

- `modPostBuild`: Shell commands to run after the build of the go-modules executes `go mod vendor`, and before calculating fixed output derivation's `vendorHash` (or `vendorSha256`). Note that if you change this attribute, you need to update `vendorHash` (or `vendorSha256`) attribute.



```nix

pet = buildGoModule rec {
@@ -114,7 +115,16 @@ done 


## Attributes used by the builders {#ssec-go-common-attributes}



Both `buildGoModule` and `buildGoPackage` can be tweaked to behave slightly differently, if the following attributes are used:

Many attributes [controlling the build phase](#variables-controlling-the-build-phase) are respected by both `buildGoModule` and `buildGoPackage`. Note that `buildGoModule` reads the following attributes also when building the `vendor/` go-modules fixed output derivation as well:



- [`sourceRoot`](#var-stdenv-sourceRoot)

- [`prePatch`](#var-stdenv-prePatch)

- [`patches`](#var-stdenv-patches)

- [`patchFlags`](#var-stdenv-patchFlags)

- [`postPatch`](#var-stdenv-postPatch)

- [`preBuild`](#var-stdenv-preBuild)



In addition to the above attributes, and the many more variables respected also by `stdenv.mkDerivation`, both `buildGoModule` and `buildGoPackage` respect Go-specific attributes that tweak them to behave slightly differently:



### `ldflags` {#var-go-ldflags}

pkgs/build-support/go/module.nix

+5 −1
Original line number Diff line number Diff line
@@ -83,12 +83,16 @@ let 
    inherit (args) src;

    inherit (go) GOOS GOARCH;



    # The following inheritence behavior is not trivial to expect, and some may

    # argue it's not ideal. Changing it may break vendor hashes in Nixpkgs and

    # out in the wild. In anycase, it's documented in:

    # doc/languages-frameworks/go.section.md

    prePatch = args.prePatch or "";

    patches = args.patches or [];

    patchFlags = args.patchFlags or [];

    postPatch = args.postPatch or "";

    preBuild = args.preBuild or "";

    postBuild = args.postBuild or "";

    postBuild = args.modPostBuild or "";

    sourceRoot = args.sourceRoot or "";



    GO111MODULE = "on";