While I can understand the standard library taking precedence, it would be nice if serveDetails would fallback to checking the other modules so that modules which are internal to a company and not expected to be available publicly could have documentation served by pkgsite as well.
Unfortunately, updating the module name is a disruption that is not yet worth the trouble.
The text was updated successfully, but these errors were encountered:
I understand the use case but I'm not sure this is something we would move forward with. Package names should always be globally unique and this namespace is reserved for the stdlib. Others might disagree. /cc @jba@julieqiu
Would the replace directive be useful here in avoiding major disruption from a module name change?
I recognize that this is understood within the Go team, and I understand why packages without a dot in the name must be preferred to come from stdlib in the event of a collision, but is this documented some place? Since starting to work with Go in 2013, I have never seen anyone say this or talk about it except for in some GitHub issues and some meetings with the Go team.
Given that godoc doesn't have this restriction and given that the go tool itself doesn't enforce such a restriction on package names, the incongruence in pkgsite is very unexpected.