| 28 Feb 2024 |
 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 |
