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.
Since Go 1.13, `GOSUMDB` defaults to "sum.golang.org", to consult the
checksum database of the main module's go.sum.
We already use the default behavior when building `go-modules`, but Go
tries to consult the checksum database again when building the module,
and fails because since it requires `cacert` and `git` which are not
propagated when building the package.
Since GO 1.13, the go command caches the lookup results and tiles in
$GOPATH[1], hence making the module directory non-deterministic.
Use the `-f` flag when removing /sumdb, for compatibility with Go 1.12
because in that version does not exists that directory.
[1] https://go.googlesource.com/proposal/+/master/design/25530-sumdb.md#command-client
When $subPackages has more than one item, the build was failing because
./ was added only to the first subPackage. This commit adds ./ to all
specified subPackages.
For some Go projects a go.mod file is included but there are no listed
dependencies. When this is encountered the Go toolchain will not create
a cache folder for downloaded dependencies which causes buildGoModule to
fail.
An example of a project like this that is widely used is:
https://github.com/golang/protobuf
This commit adds a mkdir command to ensure that the directory always
exists so it can be copied and prevent the failure.
cacert already exposes NIX_SSL_CERT_FILE in its setupHook. Fetchers and builders are already setup to use this variable and there's no need to export them manually.
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.
This change moves buildGoPackage from pkgs/development/go-modules to
pkgs/development/go-packages, so we can have buildGoModule at
pkgs/development/go-modules.
I noticed that I was seeing the Go compiler build things in parallel even when I'd set `-j1 --cores 1`. It appears that the compiler, by default, uses the number of CPUs that are available to perform a build, while nixpkgs parallelizes at the directory level.
In order to change the fewest assumptions, this explicitly tells the Go compiler to run single-threaded. The flag's documentation is:
```
-p n
the number of programs, such as build commands or
test binaries, that can be run in parallel.
The default is the number of CPUs available.
```
So this should function as expected. Feedback appreciated!
If projects uses go1.11 modules GOCACHE is required.
Also if buildGoPackage is used in a nix-shell setting we don't
want to override GOCACHE to allow incremental builds.
This should be backported to 18.09
The -x go option prints all intermediate commands used by the Go
compiler. For instance, this is pretty useful to debug Go LD_FLAGS
because the used linker command is printed.
This adds a fairly basic build for just the binaries for the Google
Cloud Print CUPS connector (gcp-cups-connector), and gcp-connector-util
to set it up in the first place. In the future I would like to
streamline the configuration more and make gcp-cups-connector a
proper NixOS service - as right now it must be run by hand.
As a user installing the program it's not interesting what go version it
was compiled against. Not more interesting than any other potential
dependencies. It also makes it harder to install or update the package.
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`.
