Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Closed
dottedmag opened this issue May 10, 2020 · 28 comments
Closed

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

dottedmag opened this issue May 10, 2020 · 28 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done. pkgsite
Milestone
pkgsite/godoc.org...

Comments

@dottedmag
Copy link
Contributor

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.
@toothrot toothrot added this to the Backlog milestone May 11, 2020
@toothrot toothrot added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label May 11, 2020
@toothrot
Copy link
Contributor

/cc @julieqiu

@mvdan
Copy link
Member

mvdan commented May 11, 2020

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

@ddevault
Copy link

Maintainer of git.sr.ht here. Please don't plow forward with replacing godoc.org without fixing all of my broken forge links :/

@julieqiu
Copy link
Member

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

@julieqiu julieqiu added NeedsFix The path to resolution is known, but the work has not been done. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels May 14, 2020
@julieqiu julieqiu mentioned this issue May 19, 2020
Closed
14 tasks
@mvdan
Copy link
Member

mvdan commented May 25, 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>

@mvdan
Copy link
Member

mvdan commented May 25, 2020

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.

@jba
Copy link
Contributor

jba commented May 26, 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 commit or revision instead of version, because versions don't always map to commits (think v1.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 tree vs. blob). We want to be able to link to directories.

@mvdan
Copy link
Member

mvdan commented May 26, 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.

@jba
Copy link
Contributor

jba commented May 26, 2020

Oh, there is already a field for directories, so maybe it's not so bad. I'll file a proposal now.

@jba
Copy link
Contributor

jba commented May 26, 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
Copy link
Contributor

jba commented Jun 1, 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.

@ddevault
Copy link

ddevault commented Jun 1, 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.

@jba
Copy link
Contributor

jba commented Jun 4, 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.

@ddevault
Copy link

ddevault commented Jun 5, 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.

@jba
Copy link
Contributor

jba commented Jun 12, 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.

@ddevault
Copy link

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
Copy link

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.

@mvdan
Copy link
Member

mvdan commented Jun 12, 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.

@ddevault

This comment has been minimized.

Sign in to view
@julieqiu julieqiu changed the title pkg.go.dev: Missing links to source code for git.sr.ht x/pkgsite: Missing links to source code for git.sr.ht Jun 15, 2020
@julieqiu julieqiu mentioned this issue Jul 1, 2020
Closed
1 task
@jba jba self-assigned this Jul 27, 2020
@gopherbot
Copy link
Contributor

Change https://golang.org/cl/245039 mentions this issue: internal/source: add sourcehut templates

@ddevault
Copy link

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.

@jba
Copy link
Contributor

jba commented Jul 28, 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.

@ddevault
Copy link

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
Copy link

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

@jba
Copy link
Contributor

jba commented Jul 28, 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?

@ddevault
Copy link

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
Copy link

ddevault commented Aug 1, 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.

@jba
Copy link
Contributor

jba commented Jan 21, 2021

We discussed this issue in the last golang-tools meeting, and posted an update at #40477 (comment). 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.

@golang golang locked and limited conversation to collaborators Jan 21, 2022
@rsc rsc unassigned jba Jun 23, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done. pkgsite
Projects
None yet
Milestone
pkgsite/godoc.org-redirect
Development

No branches or pull requests
7 participants
@toothrot @dottedmag @ddevault @mvdan @julieqiu @gopherbot @jba