| 26 Oct 2023 |
 axel 🦀 | Hey @pwychowaniec, would it be alright if I dmed you? | 03:16:37 |
 pwychowaniec | sure, sure! | 05:02:12 |
 adisbladis | In reply to @joerg:thalheim.io
adisbladis: if you had to implement incremental go builds with nix (or just having the dependencies pre-compiled), how would approach the problem? I looked into that a while back and my conclusion is that it's not really feasible. But I hope I'm wrong. | 06:38:11 |
|  @lotte:chir.rs changed their profile picture. | 06:46:50 |
 Mic92 | In reply to @adis:blad.is
I looked into that a while back and my conclusion is that it's not really feasible. But I hope I'm wrong. Shouldn't building a cache like this work?
$ export GOCACHE=$out
$ xargs < packages-to-build go install | 06:56:33 |
| Mic92 | and than feed this GOCACHE into the final build again. | 06:57:00 |
| 27 Oct 2023 |
| adisbladis | Mic92: I experimented with doing that in various configurations but it didn't actually end up faster. I can't remember what the issue(s) were. | 00:49:50 |
|  @federicodschonborn:matrix.org changed their profile picture. | 01:24:19 |
| pwychowaniec | Jonas Chevalier: axel 🦀 has volunteered for maintaining Naersk - do you know what are the next steps here to implement this? 😄 | 05:41:15 |
| Mic92 | adisbladis: https://github.com/numtide/build-go-cache | 06:34:56 |
| adisbladis | In reply to @joerg:thalheim.io
adisbladis: https://github.com/numtide/build-go-cache Right, so you get one massive cache for the whole project, not any incrementality? | 06:36:06 |
| Mic92 | Just for dependencies and not the source of the project. | 06:36:53 |
| Mic92 | One could potentially split this up, but I am not seeing the benefit vs. complexity in this. | 06:37:23 |
| adisbladis | I always tried to get a recursive thing going as my motivation was to maximise reuse | 06:37:53 |
| Mic92 | I have the feeling that the eval time of this would be higher than the speed of the go compiler. | 06:38:30 |
| adisbladis | But when I did that all compiler savings were dwarfed by copying files around | 06:38:38 |
| Mic92 | the cache also speeds up proxyVendor = true; | 06:39:26 |
| Mic92 | Because we are using GOMODCACHE | 06:39:37 |
| adisbladis | (I was using gomod2nix) | 06:39:44 |
| Mic92 | Can cache entries not be symlinked into one tree from single dependencies? | 06:40:37 |
| adisbladis | I don't think so | 06:41:02 |
| adisbladis | My memory is extremely fuzzy about this | 06:41:27 |
| adisbladis | But as far as I remember it it's just a pile of files that the compiler mutates | 06:41:50 |
| Mic92 | The go cache works a bit like nix. | 06:42:00 |
| adisbladis | So merging behaviour is hard | 06:42:01 |
| Mic92 | It computes a cache key over the inputs. | 06:42:12 |
| Mic92 | Afterwards cache entries shouldn't be mutated | 06:42:21 |
| Mic92 | you can do GODEBUG=gocachehash=1 go build net to see how the hash is computed. | 06:43:11 |
 Jonas Chevalier | In reply to @pwychowaniec:matrix.org
Jonas Chevalier: axel 🦀 has volunteered for maintaining Naersk - do you know what are the next steps here to implement this? 😄 great! ping me his github handle and I will take care of the rest | 09:19:10 |
| pwychowaniec | https://github.com/AxelSilverdew :-) | 09:19:56 |
