| 22 Feb 2024 |
|  hx-markus joined the room. | 12:26:02 |
| 25 Feb 2024 |
|  @ftchrist:matrix.org joined the room. | 10:18:50 |
| 28 Feb 2024 |
 kirillrdy | Paul Meyer (katexochen): hi | 09:42:17 |
| kirillrdy | just from reading the chat from 21st of Feb, I am still not sure I understand what is "Since this wait is causing breakage in the toolchain" | 09:44:17 |
 katexochen | It is not breaking the toolchain, but the development tooling. I assume this is what prmadev from the PR meant. | 09:46:15 |
| katexochen | So currently, it is difficult to develop Projects that use Go 1.22, because things like your language server etc. won't work. | 09:47:25 |
| kirillrdy | 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 | 09:48:01 |
| kirillrdy | people can just override tools to their version of golang | 09:48:21 |
| kirillrdy | it shouldn't affect default version of golang in nixpkgs | 09:48:40 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| katexochen | let me know if anything breaks | 10:07:52 |
