x/pkgsite: detect cgo (feature request)

[firelizzard18]

What is the URL of the page with the issue?

https://pkg.go.dev/github.com/kolesa-team/go-webp/webp

What is your user agent?

N/A

Screenshot

No response

What did you do?

I'm trying to find native Go packages for various things, for example webp encoding.

What did you see happen?

I have to open up the package page and if it doesn't have a readme I have to open up the repo and manually check for CGo.

What did you expect to see?

If a package contains import "C" I would like to see an indicator on the package site and in search results.

[seankhliao]

Should it flag something that also provides a purego #23172 variant?
Or cgo without import C as in https://github.com/ebitengine/purego

[firelizzard18]

I would like this proposal/request to be specifically about detecting import "C". That is simple to detect (since pkgsite is already parsing files to get the AST for rendering documentation), a meaningful signal to provide, and unambiguous in terms of what the signal means and what it value it provides.

Most of the time "it doesn't require a C toolchain to compile" is good enough for me, because usually I'm concerned about cross-compiling to the big 3 OSes and x86/ARM. Today I'm working on something that needs to compile to WASM and run in a browser, so ebitengine/purego obviously won't work. But that does not reduce the utility of having a signal for "this package imports C" because at the very least it significantly reduces the number of packages I need to look through.

As far as "should pkgsite add other signals?", I would like that to be a separate proposal/request/discussion to keep this one focused. It seems to me that additional signals could be valuable but which signals should be provided and what value they provide is much less clear to me and I think that needs further discussion on it's own issue.

[seankhliao]

see also #39195

[adonovan]

@jba

[findleyr]

Don't you really want this to be transitive (i.e. the package or any of its dependencies uses CGo)?

(Of course, that's significantly harder).

[firelizzard18]

My use case is most often something like, "I want to find a package that implements webp image encoding without requiring cgo". In those cases, where I'm trying to find a package for a specific task, knowing if that package uses cgo directly is usually good enough. Transitive cgo detection would certainly be useful, but in most cases a package with transitive cgo usage but no direct usage is going to be a higher level framework or something, like golang.org/x/exp/shiny, and thus not something I would use pkg.go.dev's search to find. My primary use case is searching on pkg.go.dev for which non-transitive cgo detection would still be very helpful.