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

Jump to bottom

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
Open

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

dmitshur opened this issue Dec 13, 2019 · 3 comments
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Backlog

Comments

@dmitshur
Copy link
Contributor

dmitshur commented Dec 13, 2019 •
edited

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.
@dmitshur dmitshur added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Dec 13, 2019
@dmitshur dmitshur added this to the Backlog milestone Dec 13, 2019
@dmitshur dmitshur self-assigned this Dec 13, 2019
@dmitshur dmitshur mentioned this issue Dec 13, 2019
Closed
@bradfitz
Copy link
Contributor

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.

@dmitshur
Copy link
Contributor Author

dmitshur commented Dec 14, 2019 •
edited

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.

@dmitshur
Copy link
Contributor Author

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.

@dmitshur dmitshur mentioned this issue Aug 19, 2020
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Backlog
Development

No branches or pull requests
2 participants
@bradfitz @dmitshur