Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/website/content/static, x/tools/godoc/static: consider reusing repo list from x/build/repos instead of maintaining own hard-coded copy #36136

Open
dmitshur opened this issue Dec 13, 2019 · 3 comments
Assignees
Milestone

Comments

@dmitshur
Copy link
Contributor

@dmitshur dmitshur commented Dec 13, 2019

This is an extension of #36047. /cc @bradfitz

There are hard-coded lists in the static templates for x/website/cmd/golangorg and x/tools/cmd/godoc, e.g.:

https://github.com/golang/website/blob/12a8390500dd3fedb41561111a59df98883b92b9/content/static/packageroot.html#L122-L138

In theory, x/website can be modified to get the list of repos from x/build/repos and pass that list to the template. However, that would require modifying golang.org/x/tools/godoc to either be able to pass data through from x/website, or having golang.org/x/tools/godoc itself get the list from x/build.

There may or may not be a constraint about whether we should add a requirement on x/build to x/tools, since x/tools contains many stable packages, while x/build is more internal and less oriented to be imported by library modules (e.g., see #29935).

I don't think it's worth implementing right now, because it's a lot of forced changes and not a lot of benefit. But there are changes planned in order to resolve #29206, and this may become more viable after that. Filing this issue to track this task.

@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Dec 14, 2019

Rather than have anything depend on x/build, we could also expose a new gRPC endpoint for this info from maintnerd.golang.org (which we could productionize a bit more) and then godoc can get this info at runtime (and cache in memory for like 1-5 minutes) instead.

Loading

@dmitshur
Copy link
Contributor Author

@dmitshur dmitshur commented Dec 14, 2019

That is an option to consider, but I think one of the valuable use cases for x/tools/cmd/godoc is to be able to run offline, which isn't very compatible with relying on RPC calls to fetch this information.

It may be a better option for x/website/cmd/golangorg though.

It's also helpful to keep "a little copy is better than dependency" in mind; it might be okay to limit the scope of repo list de-duplication to services that are inside x/build. It's not a goal to reduce all duplication at any cost.

Loading

@dmitshur
Copy link
Contributor Author

@dmitshur dmitshur commented Aug 19, 2020

By now, I think this can be done directly in x/website without modifying x/tools/godoc, similar to how it was done in CL 229483.

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants