Go: x/pkgsite: incorrectly identifies sub-module

[codyoss]

What is the URL of the page with the issue?

https://pkg.go.dev/cloud.google.com/go?tab=subdirectories

Screenshot

What did you do?

Navigate to the page linked above.

What did you expect to see?

cloud.google.com/go/compute/metadata NOT listed as a sub-module.

What did you see instead?

cloud.google.com/go/compute/metadata listed as a sub-module.

It was it's own module at one point, but it is no longer and has not been for many releases.

[julieqiu]

It was it's own module at one point, but it is no longer and has not been for many releases.

We could dedupe the list of nested modules and packages for a given page, and not list the nested module if it is a package in that module.

On https://beta.pkg.go.dev/cloud.google.com/[email protected], compute/metadata is listed as both a package and a nested module.

[trongbq]

@julieqiu I can help on this one.

[julieqiu]

Thanks, @trongbq!

[trongbq]

@julieqiu

We could dedupe the list of nested modules and packages for a given page, and not list the nested module if it is a package in that module.

I think that is not a good approach to solve this issue. This issue happens because somehow pkgsite falsely identified compute/metadata as both package and module, but as issue states that with newer versions, compute/metadata is no longer a module.
Should we look for the fix in worker fetch instead?

[julieqiu]

This issue happens because somehow pkgsite falsely identified compute/metadata as both package and module, but as issue states that with newer versions, compute/metadata is no longer a module.

I don't think that this identification is incorrect, just that the information isn't necessarily useful in the directories section of cloud.google.com/go (https://pkg.go.dev/cloud.google.com/go#section-directories).

cloud.google.com/go/compute/metadata _technically_ is a module (https://proxy.golang.org/cloud.google.com/go/compute/metadata/@v/v0.0.0-20181115181204-d50f0e9b2506.mod), and users should be able to view that module version on pkg.go.dev (https://pkg.go.dev/cloud.google.com/go/compute/[email protected]).

However, it is likely that most (if not all) users are looking for the version of compute/metadata in cloud.google.com/go. This is why I suggested deduping the list in https://github.com/golang/go/issues/42346#issuecomment-721955330.

This wouldn't cover the case where a nested module was deleted (for example, cloud.google.com/go/compute/metadata was deleted completely from cloud.google.com/go). That might be better addressed by #41321.

Should we look for the fix in worker fetch instead?

I'm not sure I see what change could be made in the worker to fix this issue. Would you mind elaborating on what you're thinking?

[trongbq]

@julieqiu Ah I see, my assumption was wrong, thank you for such a detailed explanation.
I will start work on on this based on your suggestion in the comment above.

[gopherbot]

Change https://golang.org/cl/276592 mentions this issue: frontend: this change dedupes the list of nested module and package