go: x/pkgsite: Missing links to source code for git.sr.ht

What version of Go are you using (go version)?

N/A

Does this issue reproduce with the latest release?

N/A

What operating system and processor architecture are you using (go env)?

N/A

What did you do?

What did you expect to see?

What did you see instead?

  • Nothing.

This is a regression, https://godoc.org/gioui.org/font/opentype#Collection links to source code properly.

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 28 (16 by maintainers)

Most upvoted comments

This ticket should not be closed until this is actually finished. Support needs to be added for git.sr.ht the software, not just git.sr.ht the hosted instance. Please don’t ship pkg.go.dev while it is based on an incorrect assumption about the centralization of git hosting.

No, those are all names of git web frontend softwares. Your gitlab regex only matches gitlab.com, not any other gitlab instances like gitlab.freedesktop.org, or gitlab.alpinelinux.org, or salsa.debian.org, or any of dozens more. If you set up a regex for codeberg.org (whose software is Gitea), you won’t hit git.openprivacy.ca, or git.habd.as, or another dozen more. If you set up cgit, you might have git.zx2c4.com, but not git.kernel.org. These are free and open source git platforms which anyone can deploy to their own servers, on their own domains, and might want to host Go packges there. You can’t hardcode specific hosting providers because that’s not how it works, git isn’t centralized like that.

@ddevault this is a fine place to communicate with us. Do you happen to have a list of popular deployments? Unfortunately we can only recognize code hosting sites by URL.

We’ll add support for this before redirecting godoc.org requests.

Sorry, I wasn’t clear. I’m using regexps. E.g. ^(?P<repo>gitlab\.com/[a-z0-9A-Z_.\-]+/[a-z0-9A-Z_.\-]+).

Are all those sites sourcehut deployments?

If you hard-code git hosts you’re going to eliminate huge swaths of software, including git.sr.ht, cgit, gitweb, gogs, gitea, gitlab…

You don’t feel a responsibility to implement the right solution? It’s not that much more work, it’s just a different kind of work. You solve the problem that’s in front of you.

@mvdan I’ll do that. I need to think about it some more so it might not be before the end of the week.

Someone correctly pointed out that such meta tags have placeholders for dir, file and line, but not for anything like version, as they tend to hard-code master or HEAD. If that’s a limitation that doesn’t allow the discovery site to use meta tags, perhaps we could extend them for proper module support.

We discussed this issue in the last golang-tools meeting, and posted an update at https://github.com/golang/go/issues/40477#issuecomment-764963287. We’re sorry that the communication has been spread across multiple threads, which may have made the conversation hard to follow.

We plan to use #40477 going forward. Please follow up on that thread with any comments.

I’m not going to make a Google account to comment on that changeset, can someone please pass along this message: git.sr.ht is not the only host which is running a sourcehut instance. It’s free software and can be deployed to any host.

If we’re going to update the tag format, can we please take the opportunity to make it less blatantly Go-specific? It makes me queasy to add support code for hosting any particular programming language to my git hosting platform.

Also cc @eliasnaur. I don’t think we had noticed this bug before.