←back to thread

Go is still not good

(blog.habets.se)
644 points ustad | 2 comments | 22 Aug 25 09:25 UTC | HN request time: 0.006s | source
Show context
quectophoton ◴[22 Aug 25 12:54 UTC] No.44984037[source]▶
In practice, none of these thing mentioned in the article have been an issue for me, at all. (Upvoted anyway)

What has been an issue for me, though, is working with private repositories outside GitHub (and I have to clarify that, because working with private repositories on GitHub is different, because Go has hardcoded settings specifically to make GitHub work).

I had hopes for the GOAUTH environment variable, but either (1) I'm more dumb and blind than I thought I already was, or (2) there's still no way to force Go to fetch a module using SSH without trying an HTTPS request first. And no, `GOPRIVATE="mymodule"` and `GOPROXY="direct"` don't do the trick, not even combined with Git's `insteadOf`.

replies(1): >>44985261 #
1. Tohsig ◴[22 Aug 25 14:41 UTC] No.44985261[source]▶
Definitely not just you. At my previous job we had a need to fetch private Go modules from Gitlab and, later, a self-hosted instance of Forgejo. CTO and I spent a full day or so doing trial and error to get a clean solution. If I recall correctly, we ultimately resorted to each developer adding `GOPRIVATE={module_namespace}` to their environment and adding the following to their `.netrc`:

``` machine {server} # e.g. gitlab.com login {username} password {read_only_api_key} # Must be actual key and not an ENV var ```

Worked consistently, but not a solution we were thrilled with.

replies(1): >>45006021 #
2. Tohsig ◴[24 Aug 25 17:29 UTC] No.45006021[source]▶
Fixing my formatting in case this proves useful to anyone:

  machine {server} # e.g. gitlab.com
  login {username}
  password {read_only_api_key} # Must be actual key and not an ENV var