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?
- Go to https://pkg.go.dev/gioui.org/font/opentype?tab=doc#Collection
- Click on "type Collection"
What did you expect to see?
- Browser navigated to https://git.sr.ht/~eliasnaur/gio/tree/master/font/opentype/opentype.go#L29
What did you see instead?
- Nothing.
This is a regression, https://godoc.org/gioui.org/font/opentype#Collection links to source code properly.
dottedmag
All 27 comments
/cc @julieqiu
toothrot
on 11 May 2020
Also cc @eliasnaur. I don't think we had noticed this bug before.
mvdan
on 11 May 2020
Maintainer of git.sr.ht here. Please don't plow forward with replacing godoc.org without fixing all of my broken forge links :/
ddevault
on 14 May 2020
We'll add support for this before redirecting godoc.org requests.
julieqiu
on 14 May 2020
@julieqiu out of curiosity, couldn't pkg.go.dev support any source code hosting site that's properly declared via the go-source meta tag?
$ curl https://gioui.org/?go-get=1
<html><head>
<meta name="go-import" content="gioui.org git https://git.sr.ht/~eliasnaur/gio">
<meta name="go-source" content="gioui.org _ https://git.sr.ht/~eliasnaur/gio/tree/master{/dir} https://git.sr.ht/~eliasnaur/gio/tree/master{/dir}/{file}#L{line}">
</head></html>
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.
mvdan
on 25 May 2020
I've been thinking of writing a proposal for that. It's a bit more complicated than adding version, I'm afraid:
- We'd want
commitorrevisioninstead ofversion, because versions don't always map to commits (thinkv1.2.3+incompatible, for example). The hard part there is just finding a name everyone agrees on. - Some VCSs have different URLs for directories and files (e.g. GitHub's
treevs.blob). We want to be able to link to directories.
jba
on 26 May 2020
@jba good points. If you want to lead a proposal for this, might I suggest starting a google doc where people can leave comments as input? We'll need input from users experienced in different code hosting sites, so I think that should happen before the proposal is posted.
mvdan
on 26 May 2020
Oh, there is already a field for directories, so maybe it's not so bad. I'll file a proposal now.
jba
on 26 May 2020
@mvdan I'll do that. I need to think about it some more so it might not be before the end of the week.
jba
on 27 May 2020
Here is a draft proposal for a new module-aware go-source tag: https://docs.google.com/document/d/1JCjDE6vXqJSvomOauEg_T808DWh25wNkyLjEvYlK63E/edit?usp=sharing.
Please comment, and share with anyone you think might have something to contribute. When the dust settles I'll create a proper proposal issue.
jba
on 1 Jun 2020
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.
ddevault
on 1 Jun 2020
@ddevault I think the only language-specific part is the word go in the tag name. But if we remove that and call it source, that feels too general. I don't think there's an IANA registry for meta tag names, but either way co-opting source for Go feels presumptuous.
jba
on 4 Jun 2020
We could call it source-code, project-source, module-source, etc. We should also bring in members of other language communities to see if they have any input.
ddevault
on 5 Jun 2020
I copied the above doc into #39559, for one more round of comments.
@ddevault, we've thought about your suggestion. As you point out, finding a common tag name would require a discussion with other language communities, which is a big undertaking with no clear timeline. While we would welcome and support a common tag, it's out of scope for us to start that process.
This issue will remain open: we have yet to implement the new meta tag.
jba
on 12 Jun 2020
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.
ddevault
on 12 Jun 2020
In other words, as the maintainer of a code forge who would have to implement this feature, you have my NACK on a Go-specific approach.
ddevault
on 12 Jun 2020
To my mind, it's more a matter of them not wanting to be responsible for such a standard. They are stretched pretty thin in general, so that makes sense to me, even when I'd also like a standard to exist.
mvdan
on 12 Jun 2020
The culture of doing the wrong thing because the right thing is harder really, really bothers me about the modern software development ethos. We used to care about doing things right. It has nothing to do with being stretched thin - if the throughput doesn't change, it just takes a bit longer to finish. Well, sometimes the correct solutions take more time. The whole pkg.go.dev affair seems rushed: it's not open source, it breaks git.sr.ht support, and there's no interest in taking your time to do it right. I really hope there's a course correction here.
ddevault
on 12 Jun 2020
Change https://golang.org/cl/245039 mentions this issue: internal/source: add sourcehut templates
gopherbot
on 28 Jul 2020
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.
ddevault
on 28 Jul 2020
@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.
jba
on 28 Jul 2020
Is there something that could be added to the go-source tag or perhaps some other kind of meta tag which would be sufficient for identifying git.sr.ht software?
ddevault
on 28 Jul 2020
If you hard-code git hosts you're going to eliminate huge swaths of software, including git.sr.ht, cgit, gitweb, gogs, gitea, gitlab...
ddevault
on 28 Jul 2020
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?
jba
on 28 Jul 2020
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
on 28 Jul 2020
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.
ddevault
on 1 Aug 2020
Related issues
stub42
路
3Comments
longzhizhi
路
3Comments
jayhuang75
路
3Comments
rsc
路
3Comments
go101
路
3Comments
Most helpful comment
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.