cmd/go: repeated run pkg@version calls hit the proxy for no apparent reason
#72944
Comments
|
Here's another interesting observation: how much the network is accessed depends a lot on whether GOPRIVATE is set or not (apparently regardless of the actual value of GOPRIVATE). Here's a testscript reproducer: I see this output from I see the same behaviour under Go tip as of go1.25-24b395119b |
|
maybe because of #59230 |
|
@seankhliao that would explain the hit on |
|
So the reason we're hitting the proxy is to get the deprecations. The When we're trying to figure out which module |
|
Sounds like this works as intended? Is there any suggestion for improvement? Otherwise perhaps we can close this. Thanks. |
|
Yes I think this is working as intended. In the discussion offline, @seankhliao suggested the proposal #43646 as a potential option to skip some of this work. That's probably the way we want to go. |
|
Thanks. Sounds like we can close this, and use #43646 (or new proposals) for potential improvements. |
|
Sorry for the delayed response.
I don't think that I guess you're going to say "just set
This feels to me like an implementation detail not a reason that it should work this way. AFAICS nothing in the module docs say anything about GOPRIVATE acting like an implicit first element. Instead, GOPRIVATE is always phrased as if it were orthogonal to the order of lookup (e.g. "GOPRIVATE — list of glob patterns of module path prefixes that should be considered private."). In general, I at least do have a workaround for now, but explaining it to people will be odd: "set In fact, given that the behaviour this behaviour is considered OK when GOPRIVATE has no relationship to any module that's being used, why not always just behave as if there's an implicit first element in GOPROXY that allows us to check the cache before doing anything else? Is there any down side to doing that? |
Go version
go version go1.24.1 linux/amd64
Output of
go envin your module/workspace:What did you do?
Ran
go run -x honnef.co/go/tools/cmd/[email protected] -versiona number of times.What did you see happen?
What did you expect to see?
I would expect the repeated runs to not hit GOPROXY at all; the module version is fully cached locally via GOMODCACHE.
Note that this is separate from
go runcaching binaries now. Even without caching of binaries, I would expect the local module cache to be sufficient so that the build can happen without hitting GOPROXY.The text was updated successfully, but these errors were encountered: