Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/pkgsite: show no. of downloads per week #41805

Open
Delta456 opened this issue Oct 6, 2020 · 4 comments
Open

x/pkgsite: show no. of downloads per week #41805

Delta456 opened this issue Oct 6, 2020 · 4 comments

Comments

@Delta456
Copy link

@Delta456 Delta456 commented Oct 6, 2020

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.

@gopherbot gopherbot added the pkgsite label Oct 6, 2020
@gopherbot gopherbot added this to the Unreleased milestone Oct 6, 2020
@jba jba modified the milestones: Unreleased, pkgsite/unplanned Oct 6, 2020
@jba
Copy link
Contributor

@jba jba commented Oct 6, 2020

cc @heschik @katiehockman @hyangah for proxy support.

@mvdan
Copy link
Member

@mvdan mvdan commented Oct 6, 2020

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.

@Delta456
Copy link
Author

@Delta456 Delta456 commented Oct 6, 2020

@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 #40203).

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

@ingvarm-gr
Copy link

@ingvarm-gr ingvarm-gr commented Oct 8, 2020

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, ...).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.