-
Notifications
You must be signed in to change notification settings - Fork 18k
x/pkgsite: support viewing a package @master #36811
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
Comments
We're actively working on designing a better flow, but the workaround for this right now is to do the following:
Note. This will also automatically fetch the module for the proxy and populate it on pkg.go.dev, if it does not already exist (per instructions at https://go.dev/about#adding-a-package). It may take a minute or two for the package to appear on pkg.go.dev, if it is not already there.
We know that this isn't the best user experience, and are working on a better workflow. |
How about a "Fetch latest version from master" link added to the bottom of pages on This is issue #37106 |
This is more relevant for tip.cuelang.org, because the @master docs on pkg.go.dev are not currently easily accessible. Hence the advice is: golang/go#36811 (comment) Therefore we code generate a redirect file based on the required version of cuelang.org/go (which is automatically updated for tip)
This is more relevant for tip.cuelang.org, because the master docs on pkg.go.dev are not currently easily accessible. Hence the advice is: golang/go#36811 (comment) Therefore we code generate a redirect file based on the required version of cuelang.org/go (which is automatically updated for tip)
…ion (#90) This is more relevant for tip.cuelang.org, because the master docs on pkg.go.dev are not currently easily accessible. Hence the advice is: golang/go#36811 (comment) Therefore we code generate a redirect file based on the required version of cuelang.org/go (which is automatically updated for tip)
Hey Julie, do you have any updates on the progress? This is a major blocker for us (u-root) to go.dev :( Thanks! |
@hugelgupf thanks for letting us know! We deprioritized this feature temporarily to work on open sourcing (#36747) and with our product/UX teams to address UX issues. I don't have an exact timeline on when this feature will be ready, but we are aiming for within the next month or so. Out of curiosity, does the workaround in #36811 (comment) work for your use case (aside from the suboptimal user experience)? |
The logic for GetVersionMap is changed so that an explicit module path is now required. All logic is also now the same for all requestedVersions (as opposed to a special case for latest). This function is only used by the frontend to check if a version exists as part of a frontend fetch, and this behavior makes more sense for that use case. Updates golang/go#36811 Updates golang/go#37002 Updates golang/go#37106 Change-Id: I415a2730daa6edc023f80c0c615521047311f35b Reviewed-on: https://team-review.git.corp.google.com/c/golang/discovery/+/744833 Reviewed-by: Jonathan Amsterdam <jba@google.com>
The frontend server is not initiated with a queue. The frontend task queue will be used to support frontend fetches. frontend.FetchAndUpdateState is added, which is a copy of worker.FetchAndUpdateState for use in testing and locally. Updates golang/go#36811 Updates golang/go#37002 Updates golang/go#37106 Change-Id: I41922d30462d2623a061aa1f207bb2b39f7b54e2 Reviewed-on: https://team-review.git.corp.google.com/c/golang/discovery/+/743102 Reviewed-by: Jonathan Amsterdam <jba@google.com>
This column will be used to display the canonical module path when a frontend fetch results in fetching an alternative module path. Updates golang/go#36811 Updates golang/go#37002 Updates golang/go#37106 Change-Id: Ie8ee6ba64ea799d264c1079c345e37d2e073da38 Reviewed-on: https://team-review.git.corp.google.com/c/golang/discovery/+/751268 Reviewed-by: Jonathan Amsterdam <jba@google.com>
The version_map.go_mod_path column is now populated in UpsertVersionMap. Updates golang/go#36811 Updates golang/go#37002 Updates golang/go#37106 Change-Id: I4e474d28bee67caf7625045082df46f93394f3f6 Reviewed-on: https://team-review.git.corp.google.com/c/golang/discovery/+/751269 Reviewed-by: Jonathan Amsterdam <jba@google.com>
FetchAndUpdateState in internal/frontend and internal/worker now insert the GoModPath field on VersionMap. Updates golang/go#36811 Updates golang/go#37002 Updates golang/go#37106 Change-Id: Idfce6d685d24d915608acc1748a84b9db5312ae4 Reviewed-on: https://team-review.git.corp.google.com/c/golang/discovery/+/751270 CI-Result: Cloud Build <devtools-proctor-result-processor@system.gserviceaccount.com> Reviewed-by: Jonathan Amsterdam <jba@google.com>
A fetch endpoint is added to the frontend, which will queue a module to be enqueued by the worker, if it doesn't already exist in the database. After enqueuing, the fetch handler will poll the version_map table at a constant rate, until the path returns or the request times out. If the request fails, a corresponding statusCode and responseText will be returned to be displayed to the user. Updates golang/go#36811 Updates golang/go#37002 Updates golang/go#37106 Change-Id: Ic2e20146dc626bf296db05bc2abbfb50d6fd7991 Reviewed-on: https://team-review.git.corp.google.com/c/golang/discovery/+/743103 CI-Result: Cloud Build <devtools-proctor-result-processor@system.gserviceaccount.com> Reviewed-by: Jonathan Amsterdam <jba@google.com>
isSupportedVersion is added. master is now a supported version if the feature flag ExperimentFrontendPackageAtMaster is on. Updates golang/go#36811 Change-Id: Ib1c885a5e75cb697b8e99fd8e8c9a347e2b344ed Reviewed-on: https://team-review.git.corp.google.com/c/golang/discovery/+/753605 CI-Result: Cloud Build <devtools-proctor-result-processor@system.gserviceaccount.com> Reviewed-by: Jonathan Amsterdam <jba@google.com>
When a path page 404s, it will now render the notfound.tmpl page (once the frontend-fetch feature flag is on), which provides a button for the user to make a request to fetch the package. Updates golang/go#36811 Updates golang/go#37002 Updates golang/go#37106 Change-Id: I17fedd018435e8d3e51e2a2a4a972d3cf673df56 Reviewed-on: https://team-review.git.corp.google.com/c/golang/discovery/+/753606 CI-Result: Cloud Build <devtools-proctor-result-processor@system.gserviceaccount.com> Reviewed-by: Jonathan Amsterdam <jba@google.com>
Change https://golang.org/cl/245437 mentions this issue: |
Change https://golang.org/cl/245402 mentions this issue: |
Change https://golang.org/cl/245401 mentions this issue: |
Class names with the prefix "Fetch" are alphabetized relative to each other. No changes are made to the CSS. For golang/go#36811 For golang/go#37002 Change-Id: I662829fd50f1e1634cc891ba50c4bf1d4f9ac0bd Reviewed-on: https://go-review.googlesource.com/c/pkgsite/+/245437 Reviewed-by: Jonathan Amsterdam <jba@google.com>
At the moment, when module is fetched with a status 40x, it is deleted from the database. However, we don't want to delete that module from version_map, otherwise the response will never be returned to the user for a frontend fetch. Modules with status 40x are now deleted first, and then the result is inserted into version_map and module_version_states. For golang/go#36811 For golang/go#37002 Change-Id: I5eb9414c065bdc8364445edb293f21bbe870fa43 Reviewed-on: https://go-review.googlesource.com/c/pkgsite/+/245402 Reviewed-by: Jonathan Amsterdam <jba@google.com>
For golang/go#36811 For golang/go#37002 Change-Id: I3438a8d72617f3c7af88310469b4799a5539616e Reviewed-on: https://go-review.googlesource.com/c/pkgsite/+/245401 Reviewed-by: Jonathan Amsterdam <jba@google.com> Reviewed-by: Jamal Carvalho <jamal@golang.org>
Change https://golang.org/cl/245640 mentions this issue: |
The response text for different frontend fetch outcomes is updated. The code in fetchRequestStatusAndResponseText is also refactored. For golang/go#36811 For golang/go#37002 Change-Id: I175921acde5edc5cbf677eb1d1f23171b40318b9 Reviewed-on: https://go-review.googlesource.com/c/pkgsite/+/245640 Run-TryBot: Julie Qiu <julie@golang.org> Reviewed-by: Jonathan Amsterdam <jba@google.com> Reviewed-by: Jamal Carvalho <jamal@golang.org> TryBot-Result: kokoro <noreply+kokoro@google.com>
Change https://golang.org/cl/245646 mentions this issue: |
For golang/go#36811 For golang/go#37002 Change-Id: I1853ecf2798e717589bb81ad0d749a3f814b55ec Reviewed-on: https://go-review.googlesource.com/c/pkgsite/+/245646 Reviewed-by: Jonathan Amsterdam <jba@google.com>
You can now view a package at master using the URL, |
Are there limits to this? With the exception of the example you posted, none of the common packages I use appear to work. They all use vanity URLs, so maybe this has something to do with it? |
@SamWhited - mind sharing what they are? I can look into it. |
@julieqiu here are two of mine that appear to be exhibiting this behavior: https://pkg.go.dev/code.soquee.net/otp@master or https://pkg.go.dev/mellium.im/xmpp@master |
Oh, apparently I have to "request" them or it 404s? I hadn't visited the actual page to click the link. I don't know what that means, but it's confusing |
The reason is because Feel free to file a new issue with any UI suggestions. |
Hi @julieqiu, a lot of repositories are now moving to renaming their default branches to Let me know if I should open another issue for this. Thanks! |
@hugelgupf - this issue is closed. Please open a new issue. FWIW the means by which
which then updates the following:
|
In my experience, this only seems fixed for vanity URLs. More general module names don't work, like https://pkg.go.dev/github.com/anacrolix/torrent@master. |
This is broken for https://pkg.go.dev/github.com/anacrolix/torrent@master, is it related to this? |
Fixes broken go doc: golang/go#36811 (comment)
What is the URL of the page with the issue?
https://pkg.go.dev/github.com/moby/moby/client?tab=doc
What is your user agent?
Screenshot
What did you do?
Visited the aforementioned link.
What did you expect to see?
The current docs for
github.com/moby/moby/client
, like on godoc:https://godoc.org/github.com/docker/docker/client
(notice https://github.com/docker/docker redirects to https://github.com/moby/moby)
What did you see instead?
Per the screenshot, at the time of writing, docs for v1.13.1, which was tagged on Feb 8, 2017.
The godoc version is looking at
~master
at any given moment in time.The current advice from the project maintainers is to use
master
of this package/module:client.NewClientWithOpts
in Go SDK moby/moby#40185 (comment)Hence only godoc.org works as a means of viewing "current" docs for
github.com/moby/moby/client
.The text was updated successfully, but these errors were encountered: