When modSha256 is null, disable the nix sandbox instead of using a
fixed-output derivation. This requires the nix-daemon to have
`sandbox = relaxed` set in their config to work properly.
Because the output is (hopefully) deterministic based on the inputs,
this should give a reproducible output. This is useful for development
outside of nixpkgs where re-generating the modSha256 on each mod.sum
changes is cumbersome.
Don't use this in nixpkgs! This is why null is not the default value.
The function buildGoModule builds Go programs managed with Go modules. It builds
a Go module through a two phase build:
- An intermediate fetcher derivation. This derivation will be used to
fetch all of the dependencies of the Go module.
- A final derivation will use the output of the intermediate derivation
to build the binaries and produce the final output.
After #16017 there were a lot
of comments saying that `nix` would be better than `JSON`
for Go packages dependency sets.
As said in https://github.com/NixOS/nixpkgs/pull/16017#issuecomment-229624046
> Because of the content-addressable store, if two programs have the
> same dependency it will already result in the same derivation in
> the
> store. Git also has compression in the pack files so it won't make
> much difference to duplicate the dependencies on disk. And finally
> most users will just use the binary builds so it won't make any
> differences to them.
This PR removes `libs.json` file and puts all package dependencies in
theirs `deps.json`.
There's no change in content except for amending the title of the
section to mention "frameworks", as e.g. I don't consider Qt a language,
and it's likely there will be more of similar cases in future.
To be certain, I checked diff of the generated HTMLs.
