Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
proposal: cmd/go: deprecate direct fallback in GOPROXY #40580
As noted in #40358, the
If you cannot access
If you fallback to
The only use case I can conceive for this feature, is if you wanted to fetch from vcs, and still retain the benefits of sumdb verification, but let me know if there is something I am missing.
Based on this understanding, it seems like there are two type of packages: accessible and inaccessible (wrt the proxy/sumbd). The former case are things that can be served by proxy.golang.org, or your (private) module proxy of choice. The latter are things that must be fetched from vcs directly. Documentation suggests using
I propose we remove the
While this may seems like we are forcing people to use
While we could also leave it alone, but I hope that I have shown that
Running a sumbd without a proxy would be another use case, but it is pretty weak, since there are few sumdb only implementations, and most are both proxy and sumdb.
Furthermore, my main suggestion is to remove
There is still the possibility of the go proxy being unavailble while the sumdb is not. And the proxy might not have the module or be able to fetch the module while the sumdb already knows about it. Its nice to have a usable fallback to improve overall reliability.
Letting clients fetch directly also allows the proxy to loadshed requests without immediatly impacting the clients ability to get modules. Otherwise the default behaviour of clients would force them to continue to reach out to the module proxy continuing the load.
If we are assuming that general network instability needs to be solved by the toolchain, then why do we hard fail when we cannot reach sum.golang.org?
Furthermore, it is inconcevable that, for the default values, one could reach sum.golang.org, but not proxy.golang.org, since they are the same service. This reflects all internal module deployments that i have seen too.
Im certain if given the access controls or due to the right set of circumstances to disable traffic to proxy.golang.org while sum.golang.org will be fine.
They may or may not be currently. They dont have to be in the future and they dont have to use the same load balancer config.
The go command does not need to consult
As I said in #40358, there may be room for a usability improvement in the error messages, but I don't think there's much chance at all of this proposal being accepted.