| 28 Feb 2024 |
 Diamond (it/she) | hmm, if we do want to entertain the idea of fearing 1.x+1.0 releases, I think having a buildGoLatestModule would actually make a lot of sense, considering how it would work really well for Go development tools while other Go programs that can work with existing Go versions can stay on that version | 10:11:31 |
| Diamond (it/she) | (though staying on Go versions is kind of weird because Go deprecates its releases very quickly) | 10:11:51 |
 Paul Meyer (katexochen) | In reply to @diamondburned:matrix.org
hmm, if we do want to entertain the idea of fearing 1.x+1.0 releases, I think having a buildGoLatestModule would actually make a lot of sense, considering how it would work really well for Go development tools while other Go programs that can work with existing Go versions can stay on that version I think we should rather convince people not to fear .0 releases 😉 | 10:18:47 |
| Paul Meyer (katexochen) | I also looked into removing Go 1.20, as it is EOL since some weeks. But I couldn't fix the remaining packages relying on it yet. | 10:20:43 |
 kirillrdy | feel free ping me, and/ro marsam ( maybe he doesn't use matrix ) | 10:23:45 |
| Paul Meyer (katexochen) | In reply to @kirillrdy:matrix.org
feel free ping me, and/ro marsam ( maybe he doesn't use matrix ) Thanks, will do. I hope I'll find some time for it this weekend. | 10:25:33 |
| Paul Meyer (katexochen) | kirillrdy: Have you seen my PRs on buildGoModule? I'm still looking for someone to merge
https://github.com/NixOS/nixpkgs/pull/279391 and
https://github.com/NixOS/nixpkgs/pull/278115 | 10:29:00 |
| Paul Meyer (katexochen) | As well as for some early feedback on https://github.com/NixOS/nixpkgs/pull/284568 | 10:29:37 |
| kirillrdy | no i have not, I am happy to have a look at them | 10:31:04 |
| 4 Mar 2024 |
 Sandro 🐧 | Do we have some script/GHA/etc to extract the vendor hash when updating golang dependencies, so that it can be automatically updated for a git flake in the same repo? | 10:14:07 |
| Paul Meyer (katexochen) | In reply to @sandro:supersandro.de
Do we have some script/GHA/etc to extract the vendor hash when updating golang dependencies, so that it can be automatically updated for a git flake in the same repo? Is nix-update --version=skip --flake attr what you are looking for? | 14:19:25 |
| Sandro 🐧 | Does that work when I am in the upstream repo itself and just want to update the vendorHash? | 14:20:00 |
| Paul Meyer (katexochen) | it does | 14:20:22 |
| Paul Meyer (katexochen) | We use renovate at work to update Go deps, and the following action to push vendorHash updates on renovate PRs:
https://github.com/edgelesssys/uplosi/blob/main/.github/workflows/lint.yml#L85-L126 | 14:22:02 |
 adamcstephens 🐝 | So it looks like just running nix-update then? | 14:52:56 |
| adamcstephens 🐝 | * So it looks like just running nix-update and skipping the version then? | 14:53:40 |
| Diamond (it/she) | personally if I'm having a workflow for my own repo, I tend to use gomod2nix and have it maintain that instead of the vendorHash | 14:54:45 |
| Diamond (it/she) | something like this: https://github.com/diamondburned/dissent/blob/main/.github/workflows/publish.yml#L30-L65 | 14:55:17 |
| 5 Mar 2024 |
|  渔棠 joined the room. | 03:21:28 |
| Sandro 🐧 | In reply to @diamondburned:matrix.org
personally if I'm having a workflow for my own repo, I tend to use gomod2nix and have it maintain that instead of the vendorHash That brings a whole bunch of new problems with it, especially since go is such picky about it's deps | 10:31:06 |
| Diamond (it/she) | what are the problems? | 10:57:58 |
| Sandro 🐧 | The previous version of such a tool, vgo2nix, just didn't worked with some combination of dependencies | 13:50:21 |
| Sandro 🐧 | also it makes remote building a pain | 13:50:28 |
| Sandro 🐧 | * also it makes remote building a take a longer time | 13:50:35 |
| Diamond (it/she) | In reply to @sandro:supersandro.de
The previous version of such a tool, vgo2nix, just didn't worked with some combination of dependencies hm, never had such a program with gomod2nix | 14:06:37 |
| Diamond (it/she) | not too sure about remote building either | 14:06:46 |
| Diamond (it/she) | * hm, never had such a problem with gomod2nix | 14:07:02 |
| Diamond (it/she) | given how it works, that would make sense | 14:07:12 |
| adamcstephens 🐝 | if it splits all the deps into individual derivations, then remote building will be slower due to its inefficient ways of handing off builds | 14:07:26 |
| Diamond (it/she) | but it also seems fairly minor? especially when you can probably easily override that if you don't already have them on some cache | 14:07:39 |
