Add monthly downloads badge to README

[ayushjain01]

Added a monthly downloads badge by pip Trends to the README.
View more at - https://piptrends.com/widgets/numpy

[charris]

I don't think this adds much and is mostly covered by the PyPI downloads.

[seberg]

Thanks, but I agree with @charris, seems like the same info that is already there. (to be honest, I am not sure we need this anyway, I don't think we have to convince anyone that NumPy is used a lot.)

So closing.

[ngoldbaum]

This looks like a way to drive traffic to piptrends.com, which appears to be a commercial enterprise. I don't think we should do that.

[ayushjain01]

Hi, I have reopened a PR addressing the comments from here.

@charris - While PyPI downloads provide useful data, the pip Trends badge offers more accurate and daily refreshed statistics, showing significant differences in download counts.

@seberg - The goal isn't to convince anyone of NumPy's popularity but to replace the existing badge with one that provides more precise information.

@ngoldbaum - pip Trends is not a commercial enterprise; it's an attemot aimed at supporting Python learners by providing relevant package statistics. However, I have removed the link to NumPy's pip Trends page to address your concern. The current PyPI badge links to additional information about NumPy on its PyPI page, and the pip Trends badge was intended to serve a similar purpose with more detailed stats and community-contributed content.

Thanks for your feedback.

[ayushjain01]

@seberg I couldn't edit or reopen this PR, so I opened a new one.

[mattip]

If I were you I would start with an issue to state your case:

• why we should add yet another badge to the already overloaded README,
• why the link to pip trends is a good idea for such a badge.

If that discussion is positive (and I have my doubts), only then should you submit a PR. Note that creating a PR burns up not only reviewer time, but CI resources as well.

I see you have opened other such PRs: aio-libs/aiobotocore#1118, pypa/virtualenv#2729, pyca/cryptography#11009 and more. Perhaps you could start a discussion somewhere like https://scientific-python.org/specs/ to add this proposal for a badge to recommended (or not recommened) practices for scientific python packages.

[seberg]

TBH, 4 core dev's have a preference for nothing and I have not seen new arguments. https://pypistats.org looks better and clearly a community project without any advertisement for a company or jobs.

(Basically, posting just to point out https://pypistats.org again.)

[thehesiod]

@seberg now they just need a badge :)

[seberg]

@thehesiod you can see that we have a badge and I believe it is through pypistats. We just link it to pypi, you can also make it link there.

[thehesiod]

@seberg awesome, going to swap to that too, ty!

[ayushjain01]

@mattip to address your issues -

1. Why should you add another badge - there is already a badge that indicates the download counts but has a significantly lower number of downloads, so it's not about adding a new badge but replacing it with a more accurate badge. Didn't remove it in PR to show the difference and why this badge needed to be removed.
2. Why the link is needed - the link is just to a information page about the package, very much like how the pypi downloads badge links to the pypi page. Since there were concerns of the link, I had removed the link and reopened another PR.

Talking about raising a PR directly - I believe this is what GitHub is built for - to raise PRs and make contributions. also numpy's Call to Contributors mentions Small improvements or fixes are always appreciated., which is what I believe my PR did. There were no strict guidelines suggesting to open an issue first, but I apologise for burning out the reviewer's time and CI resources. Will keep that in mind next time.

Also, going around and commenting on accepted PR's to remove the badge isn't really an appreciate move. We built something and wanted to share it with the community and that's what we did. Those who felt we added some value - accepted it, those who didn't - closed it.

If I were you I would start with an issue to state your case:

• why we should add yet another badge to the already overloaded README,
• why the link to pip trends is a good idea for such a badge.

If that discussion is positive (and I have my doubts), only then should you submit a PR. Note that creating a PR burns up not only reviewer time, but CI resources as well.

I see you have opened other such PRs: aio-libs/aiobotocore#1118, pypa/virtualenv#2729, pyca/cryptography#11009 and more. Perhaps you could start a discussion somewhere like https://scientific-python.org/specs/ to add this proposal for a badge to recommended (or not recommened) practices for scientific python packages.

[ayushjain01]

TBH, 4 core dev's have a preference for nothing and I have not seen new arguments. https://pypistats.org looks better and clearly a community project without any advertisement for a company or jobs.

(Basically, posting just to point out https://pypistats.org again.)

@seberg The career page links to Bavanti Software Solutions - under with pip trends is a community project. We don't plan on adding ads to pip Trends. pip Trends is only for learners and the community. You can check out piptrends.com and see what we're trying to do.