| 28 Feb 2024 |
 Paul Meyer (katexochen) | let me know if anything breaks | 10:07:52 |
 diamond (it/its) | In reply to@katexochen:matrix.org
Yes, but not all people seem to like early bumps: https://github.com/NixOS/nixpkgs/pull/290212#discussion_r1497626679
I still don't get why, is it because x.x.0 versions are said to be error prone? it's probably this, but I definitely agree that we've waited for way past long enough | 10:07:57 |
| diamond (it/its) | (I'm considering having a go = go_1_22 override in all my newer repos) | 10:08:18 |
| Paul Meyer (katexochen) | In reply to @diamondburned:matrix.org
it's probably this, but I definitely agree that we've waited for way past long enough Looking at the release milestones, a upstream bump from 1.x.0 -> 1.x.1 seems to resolve just as many issues as a 1.x.1 -> 1.x.2 bump on average. | 10:09:20 |
| diamond (it/its) | yeah ime 1.x.0 is never an issue either | 10:09:42 |
 kirillrdy | we should rely on automation, if something important breaks we should add a test, and not fearing of 1.23.0 release | 10:10:10 |
| Paul Meyer (katexochen) | And if packages are know to break on updates, they can still use the builder with the explicit version, so people know that manual work is needed. | 10:11:15 |
| diamond (it/its) | 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/its) | (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/its) | 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/its) | 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/its) | 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 |
