74a2950c64
It's the thing we return so no point in binding it to a temporary variable. |
||
---|---|---|
.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.