Open
Description
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.
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
seankhliao commentedon Apr 14, 2025
Should it flag something that also provides a purego #23172 variant?
Or cgo without import C as in https://github.com/ebitengine/purego
firelizzard18 commentedon Apr 14, 2025
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 commentedon Apr 14, 2025
see also #39195
adonovan commentedon Apr 15, 2025
@jba
findleyr commentedon May 15, 2025
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 commentedon May 15, 2025
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.