CC @bcmills @matloob

Anything I can do to move this forward?

I assume it needs a decision from the go core team... if accepted, I'm happy to provide a PR iff that'd be helpful.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

Talked to @bcmills and @matloob. We believe this is beyond the scope of the go command. The go-source line was defined by godoc.org before modules existed, and it provided a template to link to a specific line of a specific file in a go-get-able package. Later, the Go project adopted godoc.org and its code base but then we archived it once its replacement, pkg.go.dev, was ready. Nothing we have initiated or maintain today uses the go-source tags. In particular, neither the Go toolchain nor pkg.go.dev uses them. It seems like a mistake to add new support now, for at least two reasons:

1. The go command is not concerned with web pages about packages, which is what go-source points to. (The go command is absolutely concerned with where to find actual source files, which is now listed in the go mod download -json output, as noted earlier in the discussion.)

2. The go-source lines in widespread use provide no way to get to a web page showing the content of a file in a specific version of a module. It's ironic that they show how to get to a specific line, but that line number is almost meaningless if you don't know which version you are going to get.

Maybe it would make sense to define a replacement for go-source, but it is not a high priority, since not all module hosts may even have a web page view of every file in a module, and there is honestly limited value in being able to get to a web page about a given file.

For the use case in the top comment, I don't understand how having a web page view for a given file in a module is going to help you derive "release-related metadata, such as the release notes, changelog, commit log, etc." The only way I can see that helping is if you recognize the go-source URL as being one of a set of known URLs, such as "this is GitHub" and then change the URL to find adjacent material. But if so, it seems like using the VCS Origin URL would work just as well.

I agree that go-source is out of scope for cmd/go (and tricky to be correct in the module world). Just minor correction - pkgsite uses this as one of many hacks to guess the source locations. I think the code for querying/parsing the metatag is straightforward enough to copy and use.

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

Thanks for the thoughtful response. I haven't had time to look at this in-depth, but planning to do so in the next few days, do you mind leaving the issue open through the end of this week?

In the absence of new information the issue will be marked Declined on Wed 5/24.

No change in consensus, so declined.
— rsc for the proposal review group

Following up on this since it's still an issue we're facing in :

For the use case in the top comment, I don't understand how having a web page view for a given file in a module is going to help you derive "release-related metadata, such as the release notes, changelog, commit log, etc." The only way I can see that helping is if you recognize the go-source URL as being one of a set of known URLs, such as "this is GitHub" and then change the URL to find adjacent material.

Yes, there's only a handful of popular source code hosts, so once we know a repo URL we have some generic code that extracts that metadata and adds it to the PR.

But if so, it seems like using the VCS Origin URL would work just as well.

Unfortunately not. It's relatively common for the VCS Origin URL to be a vanity domain that's useful for go get but not where development actually takes place. See the curl results from this example.

Today, if opens a PR to bump golang.org/x/text we can include the release notes, commit log, etc because the source tag points us at https://github.com/golang/text/ which is a well-known source code host. I realize it's just a mirror, but regardless adding that info to PR's provides value for code reviewers evaluating whether to upgrade golang.org/x/text.

If we only use the VCS Origin URL, we get pointed at https://go.googlesource.com/text, so we can't grab the release metadata unless we treat the custom domain go.googlesource.com as a well-known source host.

We don't intend to dictate to library authors where to host their code--it doesn't have to be GitHub. But even in this example, that's a custom domain for the import... https://go.googlesource.com/text url isn't the actual source repo. According to https://pkg.go.dev/golang.org/x/text the source repo is actually https://cs.opensource.google/go/x/text, but there's no way for the library author to communicate that solely using the VCS Origin URL.

As long as users have the ability to set custom/vanity domains for go get / go.mod imports, then it's also useful to offer a side-channel to say "if you're interested in the release notes and commit log, this other URL is the actual development repo."

Your rationale for why the go-source tag may be the wrong solution makes sense to me. For this use case, the side channel doesn't need to point at specific lines or specific files. I suppose technically it'd be nice to tie it to specific versions if someone changed the development URL, but pragmatically that's very rare so I'm not sure I'd worry about it.

Again, all we really need here is a way for library authors who use a vanity import URL to say "here's the URL of the actual development repo".

Sorry this took so long to circle back on... I moved off the team for a bit and only recently rejoined them, plus now on paternity leave so have time to circle back on some things I personally care about.

Given that this has already been closed, and that the discussion is moving toward a generic side channel solution which may not be the go-source tag, would it be more helpful if I opened a new proposal instead?

We don't intend to dictate to library authors where to host their code--it doesn't have to be GitHub. But even in this example, that's a custom domain for the import... https://go.googlesource.com/text url isn't the actual source repo. According to https://pkg.go.dev/golang.org/x/text the source repo is actually https://cs.opensource.google/go/x/text, but there's no way for the library author to communicate that solely using the VCS Origin URL.

https://go.googlesource.com/text is the upstream repo.
https://cs.opensource.google/go/x/text is a different mirror that has better search functionality.

@jeffwidman Yes, if you want to move this forward, a new proposal with a new approach would be the way to go. I think it's clear that we aren't going to change cmd/go for this. It might be more appropriate on pkg.go.dev.