mirror of
https://github.com/tweag/gomod2nix.git
synced 2024-11-05 01:59:08 +00:00
Convert applications using Go modules to Nix expressions
509b97c288
The difference in behaviour was unfortunate. The only downside I can see is that this doesn't allow for mixed origins in the same package, which probably shouldn't be done anyway. |
||
|---|---|---|
| .github/workflows | ||
| builder | ||
| cmd | ||
| generate | ||
| lib | ||
| schema | ||
| 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;
}
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.
License
This project is licensed under the MIT License. See the LICENSE file for details.