Ignore vendorSha256 when vendorHash is specified.
Throw when vendorHash isn't specified:
- "buildGoModule: Expect vendorHash instead of vendorSha256" when
vendorSha256 is specified.
- "buildGoModule: vendorHash is missing" otherwise.
`goModules.outputHashAlgo` is specified as null when vendorHash is not
empty, "sha256" otherwise.
Co-authored-by: zowoq <59103226+zowoq@users.noreply.github.com>
Before the change there was no way to poll for presence of
`vendorSha256` attribute:
$ nix-instantiate --strict --eval --expr 'with import ./. {}; _3mux.vendorSha256 or "no hash"'
error: attribute 'vendorSha256' missing
292| passthru = passthru // { inherit go goModules vendorHash; } // { inherit (args') vendorSha256; };
| ^
After the change the poll happens as expected:
$ nix-instantiate --strict --eval --expr 'with import ./. {}; _3mux.vendorSha256 or "no hash"'
"no hash"
In 787af0f79f
I had to change ${go-modules} to $goModules to allow overrideAttrs to work;
However, env vars cannot contain -, so i had to change go-modules too.
This in turn broke nix-update because it uses the go-modules attr.
Instead of making nix-update more complicated, make go-modules naming match cargoDeps.
`fd --type f | xargs sd '\bgo-modules\b' 'goModules'`
and revert change to pkgs/applications/misc/dstask/default.nix
and pkgs/servers/http/dave/default.nix
and pkgs/os-specific/darwin/plistwatch/default.nix
release note added
* buildGoModule: don't inherit postBuild hook when building go-modules
This is a slight revert of 5ce647b8bf
(#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: Sandro <sandro.jaeckel@gmail.com>
This was pretty straightforward, note that go1.17 is explicitly required
by v0.5.1, and one of the tests requires git, so I added it to the
checkInputs.
Also the tests now pass and don't need the mangle, so I removed the
patch. I left the darwin/aarch64 patch in.
