| 25 Mar 2024 |
 stv0g | Oh yeah, sorry | 18:51:49 |
| stv0g | This is my current attempt:
pkgs.runCommand "ginkgo" {
nativeBuildInputs = [
pkgs.go
];
} ''
export HOME=$(pwd)
export GO111MODULE=off
export GOPATH=$out
mkdir -p $GOPATH
ln -s ${packages.go-babel.goModules} $out/src
go install -v -n -a github.com/onsi/ginkgo/v2/ginkgo
# mkdir -p $out/bin
# ls -l /build/bin/
# mv /build/bin/ginkgo $out/bin
'';
| 18:52:15 |
 @qbit:tapenet.org | so you have ginkgo in nixpkgs | 18:52:30 |
| @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 |
| @qbit:tapenet.org | just to be sure | 19:01:00 |
| stv0g | Okay also a instresting idea.. But that could still be a different version from whats acutally used by my code I assume.. I would need to check the go.sum file to be 100% certain | 19:07:04 |
| @qbit:tapenet.org | so like: go build -o $out/bin/gnkgo github.com/onsi/ginkgo/v2/ginkgo@$(grep ginkgo go.mod | awk '{print $NF}' | 19:09:32 |
| @qbit:tapenet.org | * so like: go build -o $out/bin/gnkgo github.com/onsi/ginkgo/v2/ginkgo@$(grep ginkgo go.mod | awk '{print $NF}') | 19:09:36 |
| @qbit:tapenet.org | basically | 19:09:38 |
| @qbit:tapenet.org | or maybe switch it to go install | 19:09:54 |
| @qbit:tapenet.org | not sure | 19:09:57 |
| @qbit:tapenet.org | or cd vendor/...etc../ginkgo; go build -o ...... | 19:10:22 |
| @qbit:tapenet.org | in a subshell after you have vendor'd | 19:10:27 |
| 26 Mar 2024 |
 Paul Meyer (katexochen) | In reply to @stv0ge:matrix.org
Okay also a instresting idea.. But that could still be a different version from whats acutally used by my code I assume.. I would need to check the go.sum file to be 100% certain go.sum is not an exact lockfile. It can contain multiple versions of your dependencies where only one of them would be used by your code. To get the dependencies after minimal version selection (Go's dependency resolution algorithm) use go list -m all or go mod graph. | 06:43:30 |
| Paul Meyer (katexochen) | https://github.com/NixOS/nixpkgs/issues/299096 | 12:07:27 |
| @qbit:tapenet.org | go.work is one of those things I just can't understand.. | 14:59:09 |
| @qbit:tapenet.org | like the difference between update and upgrade | 14:59:16 |
 Diamond (it/she) | rn it has a Go package using workspace that has GOWORK=off in the Nix file because of this problem | 22:11:19 |
