Go: x/pkgsite: show no. of downloads per week

Created on 6 Oct 2020  路  4Comments  路  Source: golang/go

NOTE: This proposal was opened to a separate issue as told by @julieqiu The feature was originally requested here.

Nowadays almost all package registries show no. of downloads per week of packages installed by the CLI. I would like to propose the same for pkg,go.dev. Currently users have to see via Insights/Git clones for seeing how many people have installed their package via go get. This feature would be really handle for the registry and the users so they will be able to keep track of it.

We can probably show this it here. PS: I am not a designer.

image

As we don't have make to accounts to submit packages to the registry so the downloads listing will be public i.e. visible to all users by default.

Example of NPM of this feature. (public by default)
For PyPL you would have to see it via their public dataset on Google Big Query as answered here.

NeedsInvestigation pkgsite

Most helpful comment

I would say that either "number of packages/modules that has this as a (direct or indirect) dependency" is a better measure of popularity than "downloads".

Number of downloads is a proxy for "how frequently are things with this as a dependency built for the first time on a specific machine". Direct or indirect dependencies are a proxy for how many find your package/module useful. It will be a lower number, growing more slowly, but is probably a better indicator than just downloads.

Both will be skewed by a variety of factors. Only packages already indexed by pkg.go.dev will be accounted for in either a direct or indirect dependency count (this excludes a whole slew of possible packages). Downloads will be skewed by caches (on-disk module caches, Athens proxies in corporate environments, ...).

All 4 comments

cc @heschik @katiehockman @hyangah for proxy support.

I'm not sure how useful this would be; proxy.golang.org is the default for Go setups, but it's designed to not be centralized. At best, it would be "download stats for this proxy", and not "download stats for all proxies".

Also, how do you intend to prevent "gaming" the stats? If I set up some sort of bot net to download a module thousands of times per day, do I suddenly make it to the "most downloaded" lists? Note that other proxy implementations like gocenter already have download stats, but I'm not sure what useful information you can actually gather from that.

@mvdan Hey! Thanks for reaching out on this proposal. I don't have any experience on how it will work on the proxy side (I am really serious). But as an author of a package (PS: I am not advertising my package but just linking if anyone doesn't believes me), I would like to how much popular the package is. I feel this is must for package authors so that they can be motivated to add more features and fix bugs and optimize code for the users and for the users too as if the package is actually good (most judge by downloads) so they can use in their projects etc.

I have checked GoCenter but it seems to be broken and outdated with the progress of pkg.go.dev(I believe as the README.md of my package is broken and it was fixed for me recently https://github.com/golang/go/issues/40203).

Most people will also rely on the official registry of GoLang IMHO.

I would say that either "number of packages/modules that has this as a (direct or indirect) dependency" is a better measure of popularity than "downloads".

Number of downloads is a proxy for "how frequently are things with this as a dependency built for the first time on a specific machine". Direct or indirect dependencies are a proxy for how many find your package/module useful. It will be a lower number, growing more slowly, but is probably a better indicator than just downloads.

Both will be skewed by a variety of factors. Only packages already indexed by pkg.go.dev will be accounted for in either a direct or indirect dependency count (this excludes a whole slew of possible packages). Downloads will be skewed by caches (on-disk module caches, Athens proxies in corporate environments, ...).

Was this page helpful?
0 / 5 - 0 ratings