31102e0753
Few things going on in this commit:
Do not print "Building subPakage $pkg" message if actually going to skip the
package. This was confusing to me when I was trying to figure out how to set
excludedPackages and seeing the "Building subpackage $pkg" messages for
packages I wanted to skip. Turns out this messages was being printed before
checking if we actually wanted to build the package and not necessarily that my
excludedPackages was wrong.
This commit also does some setup outside the buildGoDir function so that we
avoid checking `excludedPackages` for every package and cut down the number
of grep calls by half since we always want at least one grep for the default
excludedPackages, might as well just add to the patterns being checked.
Finally, adds documentation for usage of excludedPackages and subPackages. I
had to read the implementation to figure out how to correctly use these
function arguments since there was no documentation and different uses in the
code base. So this commit documents usage of the arguments.
This is a port of
|
||
|---|---|---|
| .github/workflows | ||
| builder | ||
| docs | ||
| internal | ||
| templates/app | ||
| tests | ||
| .envrc | ||
| .gitignore | ||
| default.nix | ||
| flake.lock | ||
| flake.nix | ||
| go.mod | ||
| go.sum | ||
| gomod2nix.toml | ||
| LICENSE | ||
| main.go | ||
| overlay.nix | ||
| README.md | ||
| shell.nix | ||
Gomod2nix
Convert applications using Go modules -> Nix
Usage
From the Go project directory execute:
$ gomod2nix
This will create gomod2nix.toml that's used like so
let
pkgs = import <nixpkgs> {
overlays = [
(self: super: {
buildGoApplication = super.callPackage ./builder { };
})
];
};
in pkgs.buildGoApplication {
pname = "gomod2nix-example";
version = "0.1";
src = ./.;
modules = ./gomod2nix.toml;
}
For more in-depth usage check the Getting Started and the Nix API reference docs.
FAQ
Why not continue work on vgo2nix?
Vgo2nix was built on top of the old Nixpkgs build abstraction buildGoPackage, this abstraction was built pre-modules and suffered from some fundamental design issues with modules, such as only allowing a single version of a Go package path inside the same build closure, something that Go itself allows for.
We need a better build abstraction that takes Go modules into account, while remaining import from derivation-free.
Will this be included in Nixpkgs
Yes. Once the API is considered stable.
Motivation
The announcement blog post contains comparisons with other Go build systems for Nix and additional notes on the design choices made.
License
This project is licensed under the MIT License. See the LICENSE file for details.