Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
For example, I'd like to see https://godoc.org/github.com/hajimehoshi/vgotest/v2 available.
It'd be great to have basic support for Go modules, so that if anyone goes to the GitHub version of docs for a repo which is using vanity import paths, e.g. https://godoc.org/github.com/peerbase/peerbase/bytesize, it would try to read a go.mod file at the repo root, and redirect to that subpath on godoc.org instead, i.e. https://godoc.org/peerbase.net/go/bytesize ?
This should prevent people from seeing the non-canonical docs and import paths when projects have stopped using canonical import comments...
I would love to be able to build / view godocs interactively locally. Since we moved to using Go modules, my github repo is no longer in my GOROOT or GOPATH, but I want to be able to call
The workaround right now appears to be:
and then it "works". It would be great if it could just work from the dir I'm in without this hack.
Or maybe this comment belongs in golang/go#26827
Considering the deprecation warning on
Has this feature been assigned or would you all be interested in community assistance in design/implementation? I would imagine the community would like this to close before the 1.13 release.
Should packages display the value that customers would expect to see in a
Do we need to show docs for old version? This will be harder, and should be unnecessary if semver is used correctly.
Since modules are atomic units, should we fetch all the packages and preload them into redis?
We should be able to break this work up by VCS provider to prevent a massive CL, so as long as there are no breaking changes. However deploy ought block till they are all ready, to provide a unified UX to consumers.
Is it required to get this by the 1.13 drop?
Should we vendor the stdlib module code, reimplement what we need, or consume from somewhere else?
Should replace directives modify import links?
Should we display the
0] For clarity, yes I am offering.
https://godoc.org/github.com/nicksnyder/go-i18n just released v2 and has similar problems.
Another bit of missing support: it seems that gddo does not support this in
@Sean-Der The current godoc.org website supports Go packages that are functional in GOPATH mode. As you pointed out, if a package is available only in module mode but not in GOPATH mode, it won't show up on godoc.org.
It was mentioned in the https://blog.golang.org/modules2019 blog post (in the Module Discovery section), we are working on a new discovery site that has been designed with version support in mind and will be able to display documentation for packages that are available only in module mode.
@julieqiu gave a "Finding Dependable Go Packages" talk at GothamGo 2019 (video, slides) that discusses an aspect of the discovery site, and it included some early mockups of the discovery site at the end. You can see them starting with slide 92.
It will also support the "mod" VCS type that @darkfeline mentioned above.