| 13 Feb 2024 |
 @qbit:tapenet.org | so you likely haven't evaluated that src block yet | 19:16:11 |
 anthr76 | I can see in my build it pulls down the source tarball | 19:21:25 |
| anthr76 | In reply to @anthr76:mozilla.org
So it then failed
> fatal: could not read Username for 'https://github.com': terminal prompts disabled
> Confirm the import path was entered correctly.
> If this is a private repositor
This fails for go modules not the original go project | 19:21:36 |
| anthr76 | Here's a log of it building public go mods
[1/0/2 built] building foo-1.13.0-go-modules (buildPhase): go: downloading google.golang.org/protobuf v1.31.0
| 19:53:18 |
| anthr76 | But then gets hung up on the private ones | 19:53:29 |
| 15 Feb 2024 |
|  Diamond (it/she) joined the room. | 11:57:39 |
|  immll joined the room. | 15:29:13 |
|  chensl joined the room. | 17:35:59 |
| 20 Feb 2024 |
 Paul Meyer (katexochen) | Any opinions on introducing buildGoLatestModule so packages can specify they always must be build with the latest available Go version? Especially the Go tooling (gotools,gopls,golangci-lint) cannot be used with the latest version of Go (like currently with 1.22) in case it wasn't built with that version. Tools built with a newer version should still be backwards compatible. | 13:52:00 |
 K900 ⚡️ | Why not just bump buildGoModule then? | 13:53:55 |
| Paul Meyer (katexochen) | hm. good point. :D I'm not sure what the reason is for buildGoModule currently being the prev minor, I thought the might be some incompatibilities (which shouldn't be a thing in Go, but who knows). | 14:00:26 |
 Alyssa Ross | The problem with depending on any sort of "latest" is that then people get scared to bump "latest" and it loses its meaning. | 14:42:54 |
| Paul Meyer (katexochen) | I'll just try to bump Go. | 14:58:34 |
| Paul Meyer (katexochen) | * I'll just try to bump buildGoModule. | 14:59:00 |
| Paul Meyer (katexochen) | https://github.com/NixOS/nixpkgs/pull/290212 | 15:08:24 |
| 22 Feb 2024 |
|  hx-markus joined the room. | 12:26:02 |
| 25 Feb 2024 |
|  Frédéric Christ 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 |
| Paul Meyer (katexochen) | It is not breaking the toolchain, but the development tooling. I assume this is what prmadev from the PR meant. | 09:46:15 |
| Paul Meyer (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 |
| 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 |
