Recently I spent may hours on a very simple problem that could be detected if go mod had good logging.
I have two questions:
- If you have problems with
go modorgo getor other go tooling, how do you debug them? - How can we improve the tooling to make it easier.
I’ve been around for a while and every new go developer runs into problems with private repos. Like you don’t have access to this, or you don’t have access to that. Tooling is quite good with that problem it can directly tell you something like:
If this is a private repository, see https://golang.org/doc/faq#git_https
Which is great. But it doesn’t help all the time.
I want some more generic way to get more information on go mod logic. For example, how it decides where to go now? Was it GOPRIVATE who affected it’s logic, or GOPROXY? When it sends an https request, what modifiers does it uses?
In my case, I seen go mod getting 404 for the endpoint that is actually publicly available and return 200 OK when I send a request using curl for the very same command line.
I tried removing .gitconfig and .ssh/config, but it didn’t help. Turned out it was an old .netrc file with login and password. And I found this only after running strace and looking at all the files go mod opens.
It was quite strange for me that go by default reads .netrc and uses auth data from it. At the same time, there is no support for SSLKEYLOGFILE or http_proxy environment variables, so even when I run wireshark to capture all the data I cannot decypher it, because it’s TLS. Having a way to force go tools to proxy their requests or to write secrets in a file would be very nice.
What do you think about it? Should I create a feature request to add more verbose debugging, or SSLKEYLOGFILE/http_proxy support? Or, perhaps, you know how to better debug go mod?