Go version

go version go1.22.3 linux/amd64

Output of go env in your module/workspace:

$ go env
GO111MODULE=''
GOARCH='amd64'
GOBIN='/home/caleb/bin'
GOCACHE='/home/caleb/.cache/go-build'
GOENV='/home/caleb/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/caleb/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/caleb/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/home/caleb/apps/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/home/caleb/apps/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.22.3'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/dev/null'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build2115513799=/tmp/go-build -gno-record-gcc-switches'

What did you do?

I'm making some documentation changes in the standard library and I want to check the HTML rendered form, so I'm trying to use pkgsite to show it.

I'm using the latest version of pkgsite as of right now (v0.0.0-20240716182356-3166cf6ec5e3).

I see that pkgsite offers a -gorepo flag:

  -gorepo string
        path to Go repo on local filesystem

What did you see happen?

The copy of the repo I'm editing is in ~/apps/godev.

So I tried:

$ pkgsite -gorepo ~/apps/godev
searching GOPATH: no modules in any of the requested directories

This error message is confusing. I have no GOPATH set. GOPATH is nearly dead these days. Why does it mention GOPATH?

I take the error to mean that it doesn't like the fact that I'm invoking pkgsite from $HOME. So the next thing I can try is to make a dummy Go module to satisfy pkgsite:

$ mkdir dummy
$ cd dummy
$ go mod init dum.my
go: creating new go.mod: module dum.my
$ pkgsite -gorepo ~/apps/godev
2024/07/20 13:54:03 Info: go/packages.Load(["all"]) loaded 0 packages from . in 6.837478ms
2024/07/20 13:54:04 Info: go/packages.Load(std) loaded 289 packages from /home/caleb/apps/go in 230.607237ms
2024/07/20 13:54:04 Info: FetchDataSource: fetching dum.my@v0.0.0
2024/07/20 13:54:04 Info: FetchDataSource: fetching std@latest
2024/07/20 13:54:04 Info: FetchDataSource: fetched dum.my@v0.0.0 using <nil> in 33.458µs with error dum.my@v0.0.0: not found
2024/07/20 13:54:04 Info: Listening on addr http://localhost:8080
2024/07/20 13:54:04 Info: FetchDataSource: fetched std@latest using *fetch.goPackagesModuleGetter in 135.330912ms with error <nil>

Now the server starts, but notice that it's loading std packages from ~/apps/go, which is my GOROOT, rather than the -gorepo location that I provided. And indeed, when I visit (for example) http://localhost:8080/cmp, I see the stale documentation from GOROOT, not my edited code in ~/apps/godev.

What did you expect to see?

I expect to see rendered documentation from the -gorepo location I provided. I expect to see changes I make on disk reflected immediately. I expect flags to work as documented. I expect pkgsite to be as easy-to-use as godoc was.

Comment From: gabyhelp

Related Issues and Documentation

(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)

Comment From: seankhliao

I believe this is a dupe of #57742

Comment From: cespare

@seankhliao I read that issue, and it caused me to try a few other things I didn't mention above, such as -list=false and cding to GOROOT/src and ~/apps/godev/src first, but none of them worked.

I assume that @matloob did fix something, so I interpreted that as meaning that there's some subtlety about what #57742 is about that's different from this issue. But I'm also okay with just declaring that #57742 was never fixed and reopening that one and closing this one.

Comment From: seankhliao

Just this (without -gorepo) seems to work?

cd $(go env GOROOT)/src
pkgsite .

Comment From: cespare

@seankhliao I do not want to serve files from GOROOT. I want to serve the files out of my local repo checkout in ~/apps/godev.

One thing I tried is to set GOROOT to be ~/apps/godev, but that also doesn't work:

$ cd ~/apps/godev/src/
$ GOROOT=$(echo ~/apps/godev) pkgsite .
searching GOPATH: listing modules in .: running go with ["list" "-m" "-json"]: exit status 1:

(Another bad error message: it again mentions GOPATH, and it ends with a colon and no further text.)

In any case, I want what the -gorepo flag says it does, but it does not work. If there is some other way point pkgsite at my local checkout of the Go repo, then we should (a) make it work well, (b) document it, and (c) remove the -gorepo flag.

Comment From: seankhliao

does the go list command work in your ~/apps/godev checkout? or do you need to adjust your PATH to ensure the go binary used is the correct one?

Comment From: cespare

@seankhliao sure, if I build a go binary in my repo checkout and then override both PATH and GOROOT (effectively changing what the "installed" go is), I can get the tool to use the checkout. -gorepo is not even involved then:

$ PATH="$(echo ~/apps/godev)/bin:$PATH" GOROOT="$(echo ~/apps/godev)" pkgsite .
2024/07/21 11:47:15 Info: go/packages.Load(["all"]) loaded 305 packages from . in 156.055794ms
2024/07/21 11:47:15 Info: go/packages.Load(std) loaded 305 packages from /home/caleb/apps/godev in 243.957558ms

Comment From: matloob

@cespare Thanks for reporting this! We recognize that cmd/pkgsite's user experience is not quite there yet and appreciate you bearing with us.

There's a bug where we print searching GOPATH in the error message even in the non-GOPATH branch of an if statement.

There's a bug where we use the value of the gorepo flag before the flag is parsed. I'll send a change to fix that.

I wasn't able to get the error in https://github.com/golang/go/issues/68533#issuecomment-2241312997 but I can look into that once we fix the first two issues.

I think we should also probably remove the -gorepo flag from cmd/pkgsite. I think it's confusing to have multiple ways of telling go where your standard library is. In the rest of our tools the way to get information about standard library packages from a specific GOROOT is to set PATH so that the go command run was built from that GOROOT.

Comment From: gopherbot

Change https://go.dev/cl/600917 mentions this issue: cmd/pkgsite: fix setting gorepo flag

Comment From: hyangah

@matloob Can you close this issue if cl/600917 fixes the gorepo flag?