| 13 Feb 2024 |
 @qbit:tapenet.org | it's not ideal though - since other people will have to configure all that themselves | 19:11:27 |
 anthr76 | yes that is setup (.netrc) and works for
src = builtins.fetchGit {
url = "git@github.com:foo/bar.git";
ref = "refs/tags/v${version}";
rev = "f993f922c88345604fdea284b624a97b9a1ee604";
};
but not for the go modules themselves
| 19:12:18 |
| @qbit:tapenet.org | your ~/.netrc won't have any impact on nix's build | 19:15:04 |
| anthr76 | The access-tokens do though | 19:15:26 |
| @qbit:tapenet.org | it has to build the vendor stuff first.. then the src for your project | 19:16:00 |
| @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 |
