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/pkgsite: There doesn't appear to be a way to report packages that no longer exist #43297

Open
stellirin opened this issue Dec 21, 2020 · 5 comments

Comments

@stellirin
Copy link

@stellirin stellirin commented Dec 21, 2020

What is the URL of the page with the issue?

https://pkg.go.dev/github.com/ivorscott/gorm-zerolog

What is your user agent?

Not relevant.

Screenshot

image

What did you do?

Click the link to the package on GitHub

What did you expect to see?

Source Code

What did you see instead?

image

@gopherbot gopherbot added the pkgsite label Dec 21, 2020
@gopherbot gopherbot added this to the Unreleased milestone Dec 21, 2020
@stellirin
Copy link
Author

@stellirin stellirin commented Dec 21, 2020

I don't mean to intentionally bully this package, it's just one example of many missing packages, but in this case the pkg.go.dev page is the second hit in a Google search for gorm zerolog, under an opaque GitHub link with no description.

image

@jba
Copy link
Contributor

@jba jba commented Dec 21, 2020

Deleting the module's repo doesn't remove it from the proxy, and pkg.go.dev gets its information from the proxy:

> curl $GOPROXY/github.com/ivorscott/gorm-zerolog/@latest
{"Version":"v0.0.0-20190830215108-3775746134e9","Time":"2019-08-30T21:51:08Z"}

That's by design. It prevents "left pad" situations where someone deletes a module that many others depend on. It also fits with the module design, which decouples module zip files from source code repositories. You can provide a module to the Go ecosystem without a publicly visible source host, just by hosting the module zip file.

That said, there are still some actions that could be taken:

  • In Go 1.16, module authors will be able to retract versions of their module by annotating their go.mod file. ivorscott could retract all versions of this module. They would have to re-create the repo to do that. (We would probably still display the page, just with an indication that it has been retracted.)
  • ivorscott could contact us and request that pkg.go.dev exclude the module.
  • We could notice that the repository link is broken and disable it. Checking links at serving time would increase latency, though, so it might not be worth it.
@jba jba modified the milestones: Unreleased, pkgsite/unplanned Dec 21, 2020
@stellirin
Copy link
Author

@stellirin stellirin commented Dec 22, 2020

Thanks for the explanation, I was not aware that the Go proxy was used at all times, and this proxy behaviour does sound like a good idea as you described it.

Checking links might not be a good idea at serving time, but I assume the proxy itself is doing some periodic checks for new versions. It might make sense to somehow hook into those checks and eventually disable the pages for packages that have disappeared for an extended period?

Ultimately I don't care enough to push here for some change, but I do think there should be a process to automatically groom out abandoned packages from the live documentation to keep the documentation relevant.

@jba
Copy link
Contributor

@jba jba commented Dec 22, 2020

The problem is, it's hard to know something's abandoned unless the author specifically tells us to remove it. Even removal of the source repo might not be enough of a signal—maybe the author decided to deliver the zip directly.

I think a better way to tackle this problem is to clearly indicate certain package properties, and perhaps de-emphasize them in search, without removing the docs completely.

How did you happen to come across this package? That would give us useful information about how we could make it less likely.

@stellirin
Copy link
Author

@stellirin stellirin commented Dec 22, 2020

I simply wanted to see how others had already integrated the zerolog package as the Logger for the gorm package before doing the same thing myself. I did a Google search for gorm zerolog as shown above.

Some digging led me to an alternative, more recent fork, which is also in pkg.go.dev at https://pkg.go.dev/github.com/mpalmer/gorm-zerolog. This fork has more recent commits, accounts for API changes in the gorm package since the ivorscott fork, uses Go modules and has a v0.1.0 release, and the source code is actually available at the expected source location.

Ideally the mpalmer fork would have been shown in the Google search, but as a documentation resource I'm not sure on what criteria you could use to decide on the most relevant package to show to a user in a Google search. Is older somehow better? Does one package have more imports by other packages? More downloads from the proxy? I have no good ideas here. I only know that, for my use case, there was a better option, but for the next person to search for gorm zerolog that might not be true. ¯\_(ツ)_/¯

I also expect it depends on Google search voodoo more than anything else.

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
3 participants
You can’t perform that action at this time.