| 25 Mar 2024 |
 @qbit:tapenet.org | no need to go install it | 18:52:35 |
 stv0g | The issue is that the version in nixpkgs might not match the version in my go.mod | 18:52:55 |
| stv0g | Same is true for other Go tools like protoc-gen-go | 18:53:19 |
| @qbit:tapenet.org | seems you would have the same problem with that approach | 18:54:06 |
| stv0g | I've tried to reuse the vendor'ed modules by buildGoModule and then run "go install" with pkgs.runCommand | 18:54:30 |
| @qbit:tapenet.org | i guess it will bump the go.mod file? | 18:54:30 |
| stv0g | I guess by using the vendored modules, I am actually ignoring the go.mod already because its only used to build the goModules derivation | 18:55:21 |
| @qbit:tapenet.org | mmm, you might be able to use the FOD modules stuff via GOCACHE | 18:55:42 |
| @qbit:tapenet.org | nothing's gonna be ideal (at least that I can think of) | 18:56:09 |
| @qbit:tapenet.org | maybe vendor your deps, then just build the code locally? | 18:59:18 |
| @qbit:tapenet.org | that'd probably be the cleanest | 18:59:24 |
| stv0g | I think I got it working with:
pkgs.runCommand "ginkgo" {
nativeBuildInputs = [
pkgs.go
];
} ''
export HOME=$(pwd)
export GO111MODULE=off
export GOPATH=/build
ln -s ${packages.go-babel.goModules} src
go build -o $out/bin/ginkgo github.com/onsi/ginkgo/v2/ginkgo
'';
| 18:59:54 |
| @qbit:tapenet.org | i'd make it grep the ginkgo version from go.mod and explicitly build the version | 19:00:57 |
