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.

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

x/pkgsite: remove non-canonical spellings of github.com/BurntSushi/toml #68357

Open
arp242 opened this issue Jul 9, 2024 · 8 comments
Open
Labels
pkgsite/package-removal Issues for package removal. See https://pkg.go.dev/about#removing-a-package pkgsite

Comments

@arp242
Copy link

arp242 commented Jul 9, 2024

What is the path of the package that you would like to have removed?

github.com/burntsushi/toml, github.com/burntSushi/toml, github.com/Burntsushi/toml

Are you the owner of this package?

Yes. It's not under my username, but I've been maintaining this for the last 3 or 4 years.

See e.g. commit log, or releases page: https://github.com/BurntSushi/toml/releases

What is the reason that you could not retract this package instead?

These are outdated casing variants from before Go modules enforced this, and are always "stuck" on an old version. The correct package is https://pkg.go.dev/github.com/BurntSushi/toml.

Someone reported these outdated versions list highly in search engine results (BurntSushi/toml#416), which seems to be correct, at least for some queries in some search engines:

cap-2024-07-09T20:53:46

Overall, it doesn't strike me as helpful retaining this.

@arp242 arp242 added the pkgsite/package-removal Issues for package removal. See https://pkg.go.dev/about#removing-a-package label Jul 9, 2024
@gopherbot gopherbot added this to the Unreleased milestone Jul 9, 2024
@suzmue suzmue self-assigned this Jul 9, 2024
@findleyr
Copy link
Contributor

findleyr commented Jul 9, 2024

Due to https://go.dev/cl/576595, our exclusions are case insensitive: for normal exclusion requests, we want all spellings to be excluded.

So I don't think package removal is the solution here, it seems like we'd need to support some notion of canonicalization, or fix the search engine ranking some other way.

@suzmue suzmue removed their assignment Jul 9, 2024
@findleyr findleyr changed the title x/pkgsite: package removal request for github.com/burntsushi/toml, github.com/burntSushi/toml, github.com/Burntsushi/toml x/pkgsite: redirect non-canonical spellings of github modules Jul 9, 2024
@findleyr findleyr changed the title x/pkgsite: redirect non-canonical spellings of github modules x/pkgsite: remove non-canonical spellings of github.com/BurntSushi/toml Jul 9, 2024
@findleyr
Copy link
Contributor

findleyr commented Jul 9, 2024

Not sure what to do here. One solution may be to add a redirect to canonical spellings of module paths, but there could theoretically be module for which the non-canonical spelling is the most popular spelling.

Unfortunately, whatever the solution, it will probably not be simple, which means this is unlikely to get prioritized soon.

@findleyr findleyr modified the milestones: Unreleased, pkgsite/backlog Jul 9, 2024
@seankhliao
Copy link
Member

I suppose the project could publish v0.3.2 (highest version without go.mod + 1) adding a go.mod matching the bad casing plus a deprecation message in go.mod, with a new version for each common bad casing

@arp242
Copy link
Author

arp242 commented Jul 9, 2024

there could theoretically be module for which the non-canonical spelling is the most popular spelling.

Perhaps, but fixing just the pkgsite isn't going to break anything for anyone, and not using canonical casing with modules is a pretty broken legacy scenario.

Redirecting to the canonical version should probably be fine. This is also what godocs.io seems to do.

I'm surprised this hasn't come up before, because casing problems like this were somewhat-ish common before modules. You could enforce it with a // import "example.com/Foo" statement, but many repos didn't do that.

@findleyr
Copy link
Contributor

findleyr commented Jul 9, 2024

The simplest solution may be to add a different case sensitive type of exclusion rule, and exclude just the popular alternate spellings of this specific module.

CC @jba

@seankhliao
Copy link
Member

What about retracting all versions prior to to a go.mod being added?
retractions don't require a match of module names

@arp242
Copy link
Author

arp242 commented Jul 9, 2024

Also: it's not a huge issue for me. Someone reported it, and I thought it would be a simple fix, but if it's considered too much effort for too little benefit I'm okay with a WONTFIX.

That said, I wouldn't be surprised if this problem also exists for other modules but that no one noticed or reported it. It's taken years for someone to report it to me.

@arp242
Copy link
Author

arp242 commented Jul 10, 2024

Another solution might be to prevent indexing with a meta tag and/or add a meta rel="canonical" tag to the canonical casing. This way the existing page still works, but it won't show up in search engines (eventually).


Completely coincidentally I found another example just now; https://duckduckgo.com/?t=ffab&q=go+uuid&ia=web lists https://pkg.go.dev/github.com/google/UUID, rather than https://pkg.go.dev/github.com/google/uuid

cap-2024-07-10T04:08:49

Google seems a bit better at this though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pkgsite/package-removal Issues for package removal. See https://pkg.go.dev/about#removing-a-package pkgsite
Projects
None yet
Development

No branches or pull requests

5 participants