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: support retractions #43265

Open
jba opened this issue Dec 18, 2020 · 0 comments
Open

x/pkgsite: support retractions #43265

jba opened this issue Dec 18, 2020 · 0 comments

Comments

@jba
Copy link
Contributor

@jba jba commented Dec 18, 2020

Beginning with Go 1.16, module authors will be able to retract versions of their modules. The go command will ignore retracted versions by default.

pkg.go.dev should expose that a version is retracted.

UI Ideas

  • The page for a retracted version should show that it is retracted, and display the rationale if any.

  • In the list of module versions, retracted versions should either be displayed at the bottom, or indicated in some other way (such as a red strikethrough). They shouldn't be hidden, because someone might be using a retracted version and want to visit its page.

  • We could show which imported packages are retracted, but that depends on having precise version information about imports (that is, the build list), which we don't currently have.

Implementation

The proposal for retraction is at #24031 (comment). In brief: retraction is done by adding retract directives in go.mod files. Each directive lists a range of versions and a rationale. Only the latest go.mod file, as defined by the go command's @latest query, is authoritative.

  • The modules table should have a column that contains the information in the retract directives, perhaps as JSON. The worker parses the go.mod file and populates the column during processing.

  • The frontend reads the retractions from the latest version of a module and applies them to the module in the request.

This involves an extra DB query sometimes, but only when viewing a version that is not the latest, which is uncommon.

One wrinkle: the latest version can retract itself. In that case, finding the true latest version (the one that deserves the "LATEST" badge) requires another pass over the list of unretracted versions.

In an alternative design, there is a column modules.retracted which gives the state for each version, and the worker populates that for all versions when it is processing the latest one. This involves some subtleties:

  • Writing rows other than the current one can result in deadlocks.
  • The worker can process versions in any order, so it might see a version in a retract directive before it has processed it. Where should it store that information?

The advantages are fewer queries at serving time in some cases, and the ability to query easily for the latest unretracted version.

@jba jba added this to the pkgsite/unplanned milestone Dec 18, 2020
@jba jba self-assigned this Dec 18, 2020
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
1 participant
You can’t perform that action at this time.