| 30 May 2025 |
 @s_r:matrix.org | * yeah, exactly. I think what I would like is a specific GOMODCACHE and GOPATH for each nix shell | 18:29:47 |
| @s_r:matrix.org | so that you don't get binaries pulled from your home | 18:30:06 |
 K900 | I'm pretty sure you can do that with buildGoModule? | 18:30:21 |
| K900 | Though you'll have to keep your vendorHash in sync | 18:30:34 |
 jrick | forget GOPATH exists, the ones that matter are GOCACHE and GOMODCACHE | 18:31:18 |
| @s_r:matrix.org | I guess the thing that got me thinking about this is that I need to download any given module once, the first time I need it, but then I don't need to do that again even if I'm in a different shell | 18:34:07 |
| @s_r:matrix.org | which is convenient, but was counter intuitive at first | 18:34:32 |
| @s_r:matrix.org | I think I can live with that given that there is still a vendor hash | 18:34:55 |
| jrick | go's tooling already handles that with the module cache (albeit per-user) | 18:35:14 |
| @s_r:matrix.org | yeah, I know | 18:35:25 |
| @s_r:matrix.org | my issue is that it feels counter-nixy, but it is probably me, that's why I was asking | 18:35:49 |
| jrick | go cryptographically verifies the dependencies too so you're not going to risk building from different sources even if there is some download duplication | 18:37:19 |
| jrick | and the cache files are read-only so unless you intentionally try to break them... | 18:38:28 |
| @s_r:matrix.org | Yeah, that's probably ok | 18:38:29 |
| @s_r:matrix.org | the derivations are also build from fresh, if I understood the code right | 18:39:22 |
| @s_r:matrix.org | I guess they need to, if the build is sandboxed | 18:39:32 |
|  sleroq changed their profile picture. | 20:15:18 |
