| 25 Mar 2024 |
 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/its) | rn it has a Go package using workspace that has GOWORK=off in the Nix file because of this problem | 22:11:19 |
| diamond (it/its) | that was long ago too | 22:11:22 |
 jrick | i "get" go.work but i don't get why people are adding it to their repos on their main/master branches (might make sense on a development branch) | 22:21:09 |
| jrick | especially don't get it if they are making release tags containing it | 22:21:50 |
| 27 Mar 2024 |
| diamond (it/its) | gotk4-examples has one just to keep all submodules in sync w/ the outer one | 04:47:45 |
| diamond (it/its) | there's a github action to guarantee that | 04:47:49 |
| 28 Mar 2024 |
|  verscheures joined the room. | 10:23:21 |
| 29 Mar 2024 |
|  SebTM joined the room. | 04:22:42 |
