x/pkgsite: searching exact standard library package names

[Deleplace]

What is the URL of the page with the issue?

https://pkg.go.dev/search?q=path&m=

What is your user agent?

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36

What did you do?

Searched the exact full name of a package of the standard library : "path"

What did you expect to see?

https://pkg.go.dev/path should be the first result

What did you see instead?

there are many results, but https://pkg.go.dev/path is not in the list at all

General problem

This is similar to #41369 but more specific: when exact search terms fail to show the relevant standard library package as 1st result.

The following rule should always hold:

IF a package exists in the standard library with name FOO, AND a user is searching the exact term "FOO" in pkg.go.dev, THEN the standard library package FOO must be the 1st result in the list

I tried 284 such searches, here are my findings.

• When the full package name contains a "/" e.g. "compress/bzip", and the user is searching for the exact full name "compress/bzip", then no result list is displayed. Instead, the page is redirected to the correct stdlib package. This works 100% of the time
• When the full package name is a single word e.g. "time", and the user is searching for the exact word, then a result list is displayed. The correct stdlib package is most often the 1st result, with 5 annoying exceptions
• When the full package name contains a "/" e.g. "compress/bzip", and the user is searching for the exact last word e.g. "bzip", then a result list is displayed. The correct stdlib package is often the 1st result, with 16 annoying exceptions

The results of these 5 single-word searches are buggy:

Package	Search link	Result
path	search path	NOT FOUND
cmp	search cmp	2nd pos
maps	search maps	8th pos
plugin	search plugin	2nd pos
slices	search slices	4th pos

The results of these 16 single-word searches are buggy too, according to the rule:

Package	Search link	Result
runtime/coverage	search coverage	NOT FOUND
go/build/constraint	search constraint	3rd pos
go/constant	search constant	3rd pos
go/doc/comment	search comment	6th pos
go/format	search format	2nd pos
go/importer	search importer	2nd pos
go/types	search types	4th pos
image/color	search color	2nd pos
net/rpc	search rpc	3rd pos
regexp/syntax	search syntax	4th pos
runtime/cgo	search cgo	2nd pos
runtime/metrics	search metrics	21st pos
runtime/race	search race	5th pos
runtime/trace	search trace	5th pos
testing/slogtest	search slogtest	2nd pos
text/template/parse	search parse	11th pos

[Deleplace]

I could clone go.googlesource.com/pkgsite, analyze the code, run the server locally and observe how the stdlib is not always prioritized.

However, I don't have the same datasources as production (postgres?) so a quick fix like "boost the Score of all stdlib results" might not be the best move.

[Deleplace]

cc @matloob @jamalc @tatianab

[komuw]

Related;

1. x/pkgsite: builtin should be ranked higher in search #40622
2. x/pkgsite: standard library packages should be prioritized in search results #41369

[hyangah]

According to https://pkg.go.dev/search-help

"If the package path you specified is complete enough, matching a full package import path, you will be brought directly to the details page for the latest version of that package."

Directing to the stdlib package automatically may be too risky, but at least, I think we need to make it correctly considered as exact match and rank it the highest.

cc @jba Do you want to track this separate from #41369?

[seankhliao]

Duplicate of #41369