Closed bcmills closed 1 year ago
pkgsite is using the local repo you provide at the version it reports. Moreover, it is doing exactly what you asked. You asked for doc at the "latest" version (since you didn't specify a version), and its notion of latest is "greatest semver tag, ignoring pre-releases." That is indeed 1.19.4.
Using context@master
should work. But it doesn't; I get a 500. Passing to @jamalc for further investigation.
Using latest
for the standard library seems inconsistent with pkgsite's behaviour when passed a path for an outside module. There it will display files as is, disregarding any versioning information.
Moreover, it is doing exactly what you asked. You asked for doc at the "latest" version (since you didn't specify a version), and its notion of latest is "greatest semver tag, ignoring pre-releases." That is indeed 1.19.4.
It didn't display docs for 1.19.4. It displayed docs for 1.19. (But maybe the tags in my copy of the repo are stale?)
But also: I didn't ask it for latest
. I asked it for an unversioned path. I would expect that if I tell it a -gorepo
explicitly it should treat the checked-out version as the default version to show. (If I pointed -gorepo
at a bare repo with no checkout, then I could see defaulting to the latest release.)
Using context@master should work. But it doesn't; I get a 500. Passing to @jamalc for further investigation.
Yep. I did try context@master
, and got a 500 page claiming that it was not supported.
I believe this is working as intended. CL 347549 only mentions speeding up serving stdlib by avoiding the full zip download. This use case was never supported.
So... do we have a recommended way to test pkgsite
rendering for standard-library changes?
We should add support. As a workaround for now can you take these steps:
/src
from std
to something like golang.org/x/toolchain
.pkgsite -list=false ./src
from the repo root.@jamalc I'm trying to submit some doc/example changes to the stdlib, and struggling with this issue as well. I've tried your workaround above of renaming the module, but I get an error HTTP 424 "This page is not supported by this datasource" when requesting http://localhost:8080/golang.org/x/toolchain/context
(or other stdlib modules). Server logs:
$ pkgsite -list=false ./src
2023/06/22 21:33:42 Info: go/packages.Load(["{golang.org/x/toolchain /home/ben/h/go/src}/..."]) loaded 0 packages from ./src in 8.052336ms
2023/06/22 21:33:42 Info: Listening on addr http://localhost:8080
2023/06/22 21:33:44 Info: FetchDataSource: fetching golang.org/x/toolchain/context@latest
2023/06/22 21:33:44 Info: FetchDataSource: fetched golang.org/x/toolchain/context@latest using <nil> in 16.292µs with error golang.org/x/toolchain/context@latest: not found
2023/06/22 21:33:44 Info: FetchDataSource: fetching golang.org/x/toolchain@latest
2023/06/22 21:33:44 Info: FetchDataSource: fetched golang.org/x/toolchain@latest using <nil> in 1.534µs with error golang.org/x/toolchain@latest: not found
2023/06/22 21:33:44 Info: returning 424 (Failed Dependency) for error serveUnitPage(ctx, w, r, ds, &{golang.org/x/toolchain/context unknownModulePath latest}): servePathNotFoundPage(w, r, "golang.org/x/toolchain/context", "latest"): 424 (Failed Dependency): <nil> (epage=&{{ <nil> false false false false } {<h3 class="Error-message">This page is not supported by this datasource.</h3>} <nil>})
Interesting, its not loading any packages at startup. Does running without -list=false have the same result?
Hmm, no, running without -list=false
actually works, thanks. The first request takes several seconds, but it seems to work, and it works after that. Here are the logs:
$ pkgsite ./src
2023/06/24 10:53:00 Info: go/packages.Load(["all"]) loaded 537 packages from ./src in 169.293176ms
2023/06/24 10:53:00 Info: Listening on addr http://localhost:8080
2023/06/24 10:53:06 Info: FetchDataSource: fetching golang.org/x/toolchain/slices@latest
2023/06/24 10:53:06 Info: FetchDataSource: fetched golang.org/x/toolchain/slices@latest using <nil> in 17.403µs with error golang.org/x/toolchain/slices@latest: not found
2023/06/24 10:53:06 Info: FetchDataSource: fetching golang.org/x/toolchain@latest
2023/06/24 10:53:11 Info: FetchDataSource: fetched golang.org/x/toolchain@latest using *fetch.goPackagesModuleGetter in 4.991958955s with error <nil>
2023/06/24 10:53:12 Warning: fetching url from deps.dev: Get "https://deps.dev/_/s/go/p/golang.org%2Fx%2Ftoolchain/v/v0.0.0/exists": context deadline exceeded
I think this should work now after https://golang.org/cl/517915. You need to be in the GOROOT/src directory for it to work. It still takes a while to do the initial load of a page in the standard library but loads faster after the first are faster.
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
go
command in that GOROOT, run:What did you expect to see?
pkgsite
documentation for the version of thecontext
package in$GOROOT/src/context
.What did you see instead?
The local
pkgsite
displays documentation forgo1.19
, but claims that it comes from the repository at $(go env GOROOT).