| 15 Sep 2023 |
 farcaller | what's the best way to run go test on a go module that has a bunch of cgo deps pulled from flakes? I guess, i"m mostly curious how to run checks only via buildGoModule or something, given the module doesn't have any binary outputs. | 19:38:18 |
| 16 Sep 2023 |
|  Paul Meyer (katexochen) changed their display name from katexochen to Paul Meyer (katexochen). | 08:20:12 |
| 21 Sep 2023 |
 kidsan | Are we able to buildGoModule using go version 1.21 currently? | 11:45:12 |
 @qbit:tapenet.org | Yes | 12:09:06 |
| kidsan | Yeah I worked out the required override just now, thanks! | 12:09:46 |
|  dedmunwalk joined the room. | 23:06:59 |
| 24 Sep 2023 |
|  mib 🥐 joined the room. | 12:21:01 |
| 25 Sep 2023 |
| Paul Meyer (katexochen) | Why is buildGoModule using vendoring instead of relying on go.mod/go.sum? | 05:06:06 |
 Artturin | In reply to @katexochen:matrix.org
Why is buildGoModule using vendoring instead of relying on go.mod/go.sum? vendoring would be copying those files to the nixpkgs repo | 05:12:26 |
| Artturin | and they're not | 05:13:14 |
| Paul Meyer (katexochen) | The builder has a field vendorHash, that's what I'm talking about. As far as I understand, it creates a intermediate derivation with the vendored dependencies. | 05:14:32 |
| Artturin | I consider vendoring copying files to the repo | 05:15:10 |
| Paul Meyer (katexochen) | * The builder has a field vendorHash, that's what I'm talking about. As far as I understand, it creates an intermediate derivation with the vendored dependencies. | 05:15:11 |
| Artturin | the vendorHash thingy is just for a fod | 05:15:25 |
| Artturin | so the deps can be fetched | 05:15:29 |
| Paul Meyer (katexochen) | fod? | 05:18:44 |
| Artturin | fixed output derivation | 05:18:52 |
| Artturin | only those and impure derivations have access to network | 05:19:00 |
| Paul Meyer (katexochen) | Sure, makes sense to separate those derivations. But couldn't it use the go.sum file instead of its own hash? How would I validate the vendorHash actually is the hash of the dependencies in the go.sum file? | 05:22:52 |
| Artturin | In reply to @katexochen:matrix.org
Sure, makes sense to separate those derivations. But couldn't it use the go.sum file instead of its own hash? How would I validate the vendorHash actually is the hash of the dependencies in the go.sum file? Using a file from inside the derivation would be ifd | 05:26:48 |
| Artturin | Import from derivation | 05:26:55 |
| Artturin | Which isn't allowed in nixpkgs | 05:27:14 |
| Artturin | Files would have to be downloaded during evaluation | 05:27:25 |
| Paul Meyer (katexochen) | Got it, thanks for explaining. So dynamic derivations could potentially fix this in nixpkgs? | 05:29:43 |
| Paul Meyer (katexochen) | But isn't go vendor using the go.mod file from inside the derivation anyway to download the dependencies? | 05:32:56 |
| Paul Meyer (katexochen) | I mean how else would it know what to download. | 05:33:40 |
| Artturin | In reply to @katexochen:matrix.org
But isn't go vendor using the go.mod file from inside the derivation anyway to download the dependencies? You can check the builders nix file and see what it runa | 05:34:11 |
| Artturin | * In reply to @katexochen:matrix.org
But isn't go vendor using the go.mod file from inside the derivation anyway to download the dependencies?
You can check the builders nix file and see what it runs | 05:34:17 |
| Artturin | In reply to @katexochen:matrix.org
Got it, thanks for explaining. So dynamic derivations could potentially fix this in nixpkgs? The rfc summary says so | 05:34:54 |
| @qbit:tapenet.org | In reply to @katexochen:matrix.org
But isn't go vendor using the go.mod file from inside the derivation anyway to download the dependencies? the vendor derivation is built first, then the hash is put in the buildGoModule derivation | 12:39:17 |
