Store buildFlagsArray as Bash global array variable instead of
creating/sourcing a file containing its declaration.
buildFlagsArray is short enough, and it is not assigned in a sub-shell.
There's no reason to pass it as a file. Storing it as a variable makes
the build more efficient.
The underlying goModules derivation must have the same source root as
the overall package. sourceRoot is being propagated already, but
setSourceRoot was not. This was surely an oversight.
This is implemented in such a way that it cannot break existing
vendorHashes unless the package is using setSourceRoot already. If
that's the case, then the package is either broken or found a workaround
to do deal with this very issue (e.g. by using `cd path` in an early
phase).
A simple search (`rg setSourceRoot $(rg -l buildGoModule)`) reveals that
no such packages obviously exist in Nixpkgs.
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.
