proposal: cmd/go: add package search functionality

[GypsyCosmonaut]

Hi Go Community,

This is proposal for adding functionality of package search in go toolchain.

How it would work?

$ go search logrus

Package | Get                             | Downloads | Version | Release Date | Bugs
logrus  | hosted.site.com/sirupsen/logrus | 32002     | 3.2.4   | 01 July 2019 | 11

This would be handy and also a step towards better package management support in Go 2.

We already have web search interface for this sort of thing
https://go-search.org/
https://godoc.org/

Why not at the command line ?

-- UPDATE --

As discussed below with @jayconrod , it makes more sense to leave the search functionality for goimports than the go tool which should remain focused on building and testing.

So we'd goimports search logrus

[ALTree]

I don't think this needs to be a Go2 proposal: it's not a language change, and it could be a go mod subcommand (probably not a top level command as you propose). Changing the title accordingly.

[GypsyCosmonaut]

@ALTree I disagree.
Search top level command could have multiple subcommands instead.

$ go search -local logrus

To check if it's installed and the path it's located at.
By default if you don't mention -local flag, it would search remotely.

$ go search -history logrus

To check version history and changelog of the package

$ go search -dependencies logrus

To list all imports along with their version used in that package

$ go search -bugs logrus

To list all open or closed reported issues for the package on the package's repository

We could also have control over what info we want for the package
So the could say

$ go search -local -options 'Version|Release_Date|Info' logrus

And many more possibilities that the community would bring
Have reverted the proposal title again.

[ccbrown]

It's a little unclear to me what the use-case for this is. Is this meant to be a tool for discovery of packages? Or just a quick way to see version numbers and metadata?

Go packages can be hosted anywhere (not just GitHub), so it wouldn't always be possible to query metrics like "bugs" or "downloads". In fact, even for GitHub repositories, I'm not sure getting those metrics is really feasible. Open issues on GitHub are not always bugs, and I don't think the public can see metrics for a repo's clone counts. I also think in general Go should steer away from GitHub-specific integrations.

We already have web search interface for this sort of thing
Why not at the command line ?

"Why not" isn't really the question we should be asking when considering new features. If there's not a compelling reason for a feature, it shouldn't be added.

I'm personally not necessarily against a CLI search tool; this proposal as-is just doesn't seem very compelling to me.

[GypsyCosmonaut]

@ccbrown Agreed.
Go should indeed steer away from GitHub-specific integrations and Github hosted packages, as if in a case where the account of a package maintainer gets compromised, and malicious code gets injected into the package, it would affect projects all over the world.

This is a proposal which is the first step in the chain of improvements and iterations for having a debate on integrating search functionality and making some central package management which we can rely on as a community. I know metrics like "bugs" and "downloads" and "changelog" are not possible to track (or with precision) with Github or any other package hosting service like Gitlab. This is a proposal to bring this problem to light and that we need a better way for package discovery along with their metadata in Go with CLI.

I am changing "github.com" link in my suggestion to "hosted.site.com"

You are welcome to make your suggestions and improvements.

[agnivade]

https://index.golang.org/ is something to that effect.

[bcmills]

CC @julieqiu @ianthehat @jayconrod

[jayconrod]

@julieqiu is working on a new site for searching and discovering modules and packages. I'm not sure if they're planning on exposing an API that a command line tool could access. We've talked about having goimports use such an API for ranking, so it seems possible to me.

That said, I'm not convinced this belongs in the go tool, which should remain focused on building and testing. The go tool also has a very rigid release cycle and dependency restrictions. A standalone tool would be more flexible.

[GypsyCosmonaut]

Good point, the go tool should remain focused on building and testing. goimports serving the search functionality seems reasonable.

Updating in the proposal

[rsc]

The output shown in the top comment is not in scope for either the go command or goimports; neither would have any idea about "bug count" for example.

The discovery site (or for now godoc.org) is the mechanism for collecting and displaying that kind of information. We should probably focus on that and not command-line tools.

[GypsyCosmonaut]

The output shown in the top comment is not in scope for either the go command or goimports;

Then why not new tool, something like gofind (go-find), or gop (go-package), or something else.

neither would have any idea about "bug count" for example

Okay, excluding "bug count"

The discovery site (or for now godoc.org) is the mechanism for collecting and displaying that kind of information

Exactly. And it is tedious.

We should probably focus on that and not command-line tools

Why not command-line tool for search?

I'm sure you've used all of the following
apt search,
docker search,
vagrant cloud search,
pip search,
gem search,
cpan search
or other similar examples on other systems and for other languages.

It makes search fast and easy.

@rsc Why not in Go ?

[DeedleFake]

I'm sure you've used all of the following
apt search,
docker search,
vagrant cloud search,
pip search,
gem search,
cpan search
or other similar examples on other systems and for other languages.

Every single one of those has a central package database, though. Go does not. That being said, I don't think it would be too weird to have an optional feature for whatever module proxy server your system is using to enable search, and have it implemented for the default server.

I also think it makes more sense to integrate this into go list, rather than making it its own thing. Something like go list -search, go list -remote, or go list -proxy.

[GypsyCosmonaut]

@DeedleFake

Talking about non-centralized package management, found some tools online for decentralized package management in Go

The pioneer’s guide to GX — decentralized dependency management on IPFS

https://github.com/whyrusleeping/gx

https://github.com/enzoh/go-revolver

[rsc]

The discovery site / godoc.org is still the place where this information should live. Maybe some day there might be a command-line interface to query it, but we are still standing up the new site. In any event, the search functionality would not be in cmd/go itself.

Go list itself is also already too overloaded. I suggest we decline this. Any objections?

[jayconrod]

I'll go ahead and close this. Having this in a separate tool, possibly integrated with the discovery site or godoc.org is a good plan.

[julieqiu]

For updates on the status of the discovery site, see #33654.

[ankushchadha]

https://search.gocenter.io can be used to discover go modules.