| 13 Feb 2024 |
 anthr76 | it seems like nix uses access-token to pull the source tarbal but I've tried to pull git https on my shell (which uses netrc) and that does work should it be relative to the build? | 19:07:13 |
 @qbit:tapenet.org | nix builds are isolated from all that (to prevent other dependencies from leaking in) | 19:07:15 |
| anthr76 | yeah that makes sense | 19:07:28 |
| anthr76 | i guess I'm looking for the right hole to punch to solve a problem like this | 19:07:42 |
| anthr76 | to me having nix run go mod vendor while it has access to my token seems to make the most sense and repeatable for CI | 19:08:03 |
| @qbit:tapenet.org | so, it's basically running go mod vendor and storing that as a separate derivation in the nix store | 19:09:11 |
| @qbit:tapenet.org | the vendorHash is the hash of that derivation | 19:09:19 |
| anthr76 | So is it possibly a bug? | 19:09:37 |
| @qbit:tapenet.org | it just doesn't have the ability to pull down the deps since they are private | 19:09:38 |
| anthr76 | Because nix can access the private repo in src | 19:09:47 |
| anthr76 | This
src = builtins.fetchGit {
url = "git@github.com:foo/bar.git";
ref = "refs/tags/v${version}";
rev = "f993f922c88345604fdea284b624a97b9a1ee604";
};
Is private but nix knows to use my access-token
| 19:10:11 |
| @qbit:tapenet.org | https://nixos.wiki/wiki/Enterprise | 19:10:48 |
| @qbit:tapenet.org | seems that's what you want | 19:10:53 |
| @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 |
