x/pkgsite: Broken links for custom go-source tags (regression)

[albertito]

What did you do?

Navigate to https://pkg.go.dev/blitiri.com.ar/go/spf (or any blitiri.com.ar package).

Click on any type or function name, or any of the source files.

What did you expect to see?

I expected to be taken to the corresponding source page, e.g. https://blitiri.com.ar/git/r/spf/b/master/t/f=spf.go.html#line-49

What did you see instead?

The links are broken because {dir} is not being replaced correctly.

Context and additional information

https://blitiri.com.ar is my personal page, where I host my git and go repositories.

The git web viewer is git-arr, and has been running fine for years.

I create the https://blitiri.com.ar/go/ remote import path by hand for all my Go packages/modules. They use the meta tags as follows:

<meta name="go-import"
  content="blitiri.com.ar/go/log git https://blitiri.com.ar/repos/log" />
<meta name="go-source"
  content="blitiri.com.ar/go/log https://godoc.org/blitiri.com.ar/go/log https://blitiri.com.ar/git/r/log/b/master/t/{dir} https://blitiri.com.ar/git/r/log/b/master/t/{dir}/f={file}.html#line-{line}" />

These go-import meta tags have been working fine for years, and worked well in godoc.org and (IIRC) also in pkg.go.dev at least at some point.

I think what's happening is that {dir} is not being expanded correctly, and instead {file} contains the full path.

As an example, if you navigate to pgd's view of blitiri.com.ar/go/chasquid/internal/safeio, then click on any of the links, you can see they're broken because they are like this:

https://blitiri.com.ar/git/r/chasquid/b/master/t/%7bdir%7d/f=internal/safeio/safeio.go.html#line-26

Note how {file} is being expanded to internal/safeio/safeio.go.html, and {dir} being expanded to {dir} (sic).

Instead, {dir} should be expanding to internal/safeio/, and file to safeio.go as per the spec and historical behaviour.

This is probably related to issue #40477 in some way.

Please let me know if you need any additional information, thanks!

[jamalc]

This does look related. @jba should we close in favor of or merge this with #40477.

[jba]

@albertito I'd be happy to add templates for your hosting software. If you could just tell me what they should look like for commits other than master, like version tags and commit hashes (the latter are needed for pseudo-versions). Here is a rough spec for the templates I'm looking for: https://go.googlesource.com/pkgsite/+/master/internal/source/source.go#683.

[jba]

I looked at git-arr to try to figure this out myself, but I didn't see how to link to a file or directory with a tag. I also don't see how to get the raw bytes of a file, which isn't strictly necessary but is used to generate the proper img URLs in readmes.

[albertito]

Thanks for the offer!

However, in #40477 (comment) you said:

We still support the go-source spec (https://github.com/golang/gddo/wiki/Source-Code-Links). Any source link that worked on godoc.org should continue to work on pkg.go.dev. However, you may be taken to master (as on godoc.org) instead of the specific version you are viewing on pkg.go.dev, if that URL pattern is not supported. The code for this is at internal/source.

The go-source metadata tags I use are compliant with go-source spec, used to work in godoc.org and have not changed, yet the source links in pkg.go.dev don't work. To me that seems like a regression, or at least a contradiction in your statement.

FWIW, I much rather have a spec that enables and encourage a more independent federation and ecosystem, without having to burden the Go team and rely on your good will and energy to customize each hosting site or software. If you tell me that's no longer supported and this is the mandated way forward, I strongly think it's the wrong direction, but I will adjust my hosting software and do the custom integration. But it would also contradict your closing statement on issue #40477, I think.

Thanks for all your help and patience with this!

[jba]

Technically you are correct: that your links don't work with master is a bug. On the other hand, linking to master when the version is v1.2.3 is not a great user experience.

Why don't I make the master links work now, and when you have upgraded your software to handle tags and commits, let me know and I will generalize.

We understand the desire to have a more federated scheme, but we just don't have one that we're happy with.

[albertito]

Technically you are correct: that your links don't work with master is a bug. On the other hand, linking to master when the version is v1.2.3 is not a great user experience.

Why don't I make the master links work now, and when you have upgraded your software to handle tags and commits, let me know and I will generalize.

SGTM, thanks!

Please let me know when the fix is in and I can check the links by hand to help verify it works.

I'll let you know once git-arr supports views of tags (and maybe arbitrary commits, although it being a static generator that might not be practical).

Thanks again!

[gopherbot]

Change https://golang.org/cl/303609 mentions this issue: internal/source: handle blitiri.com.ar import paths

[jba]

@albertito This should be live.

[albertito]

Thanks! I can see that it works for my particular site now, thanks, I appreciate the workaround :)

Has the regression for the general case been fixed though? What I mentioned above (#44607 (comment) and #44607 (comment)) affects all sites relying on the go-source spec, and IIUC you committed to continue to support.

Thanks!

[jba]

Sorry I didn't respond to your last comment, but I think I answered your question at #44607 (comment).