support Go modules

[hajimehoshi]

For example, I'd like to see https://godoc.org/github.com/hajimehoshi/vgotest/v2 available.

[tav]

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...

[DeedleFake]

It would also be nice if the interface said what version it was displaying docs for, possibly with the ability to pull up the docs for specific versions as well.

[izgeri]

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 godoc -http=:6060 from my source dir and have it generate godocs.

The workaround right now appears to be:

• Put my repo in /random_path/src
• Start up godocs with godoc -goroot=/random_path -http=:6060

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

[urandom2]

@izgeri

Considering the deprecation warning on godoc, you may consider avoiding it.

@dmitris

Has this feature been assigned or would you all be interested in community assistance[0] in design/implementation? I would imagine the community would like this to close before the 1.13 release.

Questions

Version

Should packages display the value that customers would expect to see in a go.mod and where should this go?

• v1.0.0
• v0.0.0-20170412213628-49af9bddb229

Do we need to show docs for old version? This will be harder, and should be unnecessary if semver is used correctly.

Prefetch

Since modules are atomic units, should we fetch all the packages and preload them into redis?

Segmentation

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.

Timeline

Is it required to get this by the 1.13 drop?

Libraries

Should we vendor the stdlib module code, reimplement what we need, or consume from somewhere else?

Replace

Should replace directives modify import links?

Module

Should we display the go.mod or go.sum data? Should this be a new section at the module root? Should this be a section inside every package?

0] For clarity, yes I am offering.

[dolmen]

@arnottcr

I would imagine the community would like this to close before the 1.13 release.

[dolmen]

I have a Go module that has gone to v2 and it now appears on godoc.org with an incorrect import path that doesn't contain v2: https://godoc.org/github.com/blueboardio/cldr

[nicksnyder]

https://godoc.org/github.com/nicksnyder/go-i18n just released v2 and has similar problems.

• https://godoc.org/github.com/nicksnyder/go-i18n/v2/i18n doesn't exist
• https://godoc.org/github.com/nicksnyder/go-i18n shows sub packages that no longer exist
• https://godoc.org/github.com/nicksnyder/go-i18n/i18n shows the wrong import path

[Sean-Der]

This hit Pion as well

@dmitshur it looks like godoc isn't maintained. Is this on any Go team internal roadmaps at all? I would be happy to help with this.

I don't want my work to get thrown away if someone else already plans to do this.