Comment by ~adnano on ~sircmpwn/gddo
Site is up now.
REPORTED RESOLVED CLOSED
Comment by ~adnano on ~sircmpwn/gddo
Site is up now.
You may be interested in https://code.pfad.fr/vanitydoc/.
REPORTED RESOLVED CLOSED
Comment by ~adnano on ~sircmpwn/gddo
Yes, this is a result of the ongoing sr.ht outage. See https://outage.sr.ht.
REPORTED RESOLVED CLOSED
Ticket created by ~adnano on ~sircmpwn/gddo
Limit the size of in-flight zip files to avoid overloading the server with fetches.
Ticket created by ~adnano on ~sircmpwn/gddo
Use the module path instead of the import path for package refresh requests.
Comment by ~adnano on ~sircmpwn/gddo
On second thought, I don't think we should do this. The documentation for a module is guaranteed to stay the same, which allows us to cache package documentation pages. Adding nested modules to the list of directories breaks this, as they might not be added to the database until later. Nested modules seem rare enough that this probably is not so important to implement.
REPORTED RESOLVED WONT_FIX
Ticket created by ~adnano on ~sircmpwn/gddo
For example, golang.org/x/tools should list the nested module golang.org/x/tools/gopls.
Comment by ~adnano on ~sircmpwn/gddo
REPORTED RESOLVED WONT_FIX
Comment by ~adnano on ~sircmpwn/gddo
proxy.golang.org has a new cached-only endpoint which only serves cached module information. This means that requests made to that endpoint won't trigger any clones. We have been using this endpoint in production without issues for a while now.
We could run our own proxy, but that would add additional maintenance overhead. Plus, many people already use proxy.golang.org, so clones may still happen even if we don't use it. Also, I believe that the Go team attempted to address the problem of aggressive cloning a while ago.
I'm going to close this issue for now. Feel free to reopen if the module proxy is still causing you problems.