| 28 Feb 2024 |
 Paul Meyer (katexochen) | In reply to @kirillrdy:matrix.org
i cant speak for gopls, but golangci-lint needs to be built to specific version of golang you are using, therefore, there is no one default I don't think this is true. You should be able to use golangci-lint built with Go 1.21 for Go modules that only require Go 1.20 in the same way you can build them with a newer toolchain.
There is also nothing documented otherwise in the golangci-lint docs: https://golangci-lint.run/usage/install/ | 09:52:14 |
| Paul Meyer (katexochen) | In reply to @kirillrdy:matrix.org
it shouldn't affect default version of golang in nixpkgs I think it should. Go provides a backwards compatibility promise. People who work on Go expect this, rely on it and build upon it. There is no similar promise regarding forward compatibility. Keeping the Go toolchain and builder on the latest release support these guarantees provided by upstream. | 09:56:07 |
 kirillrdy | golangci-lint is just a massive collection of thirdparty tools, and many of them rely on source code of golang version they built against | 09:57:03 |
| kirillrdy | i think still main question is how this affects default version of golang for nixpkgs, i think i understand where your proposal comes from, but I would be leaning towards just bumping default golang in nixpkgs | 09:58:29 |
| Paul Meyer (katexochen) | In reply to @kirillrdy:matrix.org
golangci-lint is just a massive collection of thirdparty tools, and many of them rely on source code of golang version they built against That's true, but incompatibilities should (and seemingly are) handled by golangci-lint itself, see for example https://github.com/golangci/golangci-lint/pull/4357 | 10:00:24 |
| Paul Meyer (katexochen) | In reply to @kirillrdy:matrix.org
i think still main question is how this affects default version of golang for nixpkgs, i think i understand where your proposal comes from, but I would be leaning towards just bumping default golang in nixpkgs Not sure I get what you mean, are you saying we should prefer bumping the default over introducing a buildGoLatestModule? | 10:01:53 |
| kirillrdy | "we should prefer bumping the default over introducing a buildGoLatestModule" --> yes | 10:02:21 |
| Paul Meyer (katexochen) | Nice, thats my opinon as well. :) | 10:03:37 |
| kirillrdy | maybe less controversial, we should prefer less work, and i think currently "bumping the default" is less work | 10:03:46 |
| kirillrdy | i am building your PR now, and so far no failures :-) | 10:04:48 |
| Paul Meyer (katexochen) | In reply to @kirillrdy:matrix.org
maybe less controversial, we should prefer less work, and i think currently "bumping the default" is less work 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? | 10:05:44 |
| kirillrdy | we can work on that, as i said, this is unstable channel | 10:06:08 |
| Paul Meyer (katexochen) | let me know if anything breaks | 10:07:52 |
 Diamond (it/she) | 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/she) | (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/she) | 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/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 |
