search

dart-lang / pub-dev

The pub.dev website
https://pub.dev
BSD 3-Clause "New" or "Revised" License
771 stars 142 forks source link

Proposal: Show Weekly and Total Downloads of package #4732

Open elbeicktalat opened 3 years ago

elbeicktalat commented 3 years ago

Hey there, I don't know how to explain the idea, because I think it's clear just reading the title, other way see npm package manager.

Number of weekly downloads with a line graph. Total Downloads under the weekly Downloads, but in the same block.

Screenshot (21)

I know it's terrible design, but it's just to show what I mean, under the likes and popularity indicator is a nice position.

In conclusion I'm sure this indicator will be very helpful in terms of choices. If you need more info or anything I'll be happy to help. Thanks!

maxzod commented 2 years ago

I was here to ask for this feature it will be great to have it will help us to chose between packages based on popularity the package authors will get insights about there packages usage

Muhammed-AbdelGhany commented 2 years ago

this would be very helpful.

rrousselGit commented 2 years ago

This has been requested quite a few times.
If I remember correctly, the response from the team was something among the lines of "We're purposefully not exposing download counts because it would be unreliable due to CI/CD. Instead we're exposing 'popularity'"

maxzod commented 2 years ago

This has been requested quite a few times.
If I remember correctly, the response from the team was something among the lines of "We're purposefully not exposing download counts because it would be unreliable due to CI/CD. Instead we're exposing 'popularity'"

I think That's totally fine ,

If the the popularity based on downloads count then the CI/CD Will have the same side effects !

If they calculate it base on pub.dev search Top Packages like provider and bloc Wich we use in every Day work will not have a big search count every day i know how to use these packages and i don't need to search for them every day unless there's and update !

https://blog.npmjs.org/post/92574016600/numeric-precision-matters-how-npm-download-counts-work.html

At npm they knew this and still do it beacuse the CI/CD Will not have that big fake downloads count

Also in dart this will be less than node Since dart caches the packages globally not in the project scope

rrousselGit commented 2 years ago

I believe the popularity score is balanced to not be impacted by CI/CD

I'm on your side though. To begin with, I dislike the popularity score. It's too abstract and not precise enough.

I've seen packages with a popularity score of 98% with only 50 stars on github and not a single article about them.

It's also unclear how big the gap is between two %.
It can take months to go from 98% to 99%, or to go from 99% to 98%.
So it's impossible to know in the short term if a package is gaining or losing in popularity.

elbeicktalat commented 2 years ago

All right but we should know what they mean exactly with exposing popularity?

As @maxzod said if they get the popularity from the downloads count it will be fine, but if they consider the search count or the click times so let me say it is useless.

They should explain what is exactly the popularity.

elbeicktalat commented 2 years ago

I'm agreed with you @rrousselGit Also I have see some packages which dose exactly the same job and they have the same popularity, so there how we should make a choice?

elbeicktalat commented 2 years ago

I don't know let's see if one of the team will answer to this issue then we'll able to see if there is a way to include this feature and I hope so.

jonasfj commented 2 years ago

They should explain what is exactly the popularity.

Please, see: https://pub.dev/help/scoring#popularity

In short it's based on download counts, then we remove systems we deem to be robots, sort and rank from 100% to 0%. That's why there is a huge difference between 98% and 97% and little difference between 20% and 10%. Few people use packages with 20% or 10% popularity, so moving from 10 to 20 doesn't require a huge change the absolute number of people using the package. Where as a change from 97 to 98 implies a massive increase in the number of people using the package.

We do have some work in progress on coming up with better metrics.

maxzod commented 2 years ago

They should explain what is exactly the popularity.

Please, see: https://pub.dev/help/scoring#popularity

In short it's based on download counts, then we remove systems we deem to be robots, sort and rank from 100% to 0%. That's why there is a huge difference between 98% and 97% and little difference between 20% and 10%. Few people use packages with 20% or 10% popularity, so moving from 10 to 20 doesn't require a huge change the absolute number of people using the package. Where as a change from 97 to 98 implies a massive increase in the number of people using the package.

We do have some work in progress on coming up with better metrics.

Is. It possible to list downloads count after removing the Robots ? That wont misslead any one since it is the same numbers used for the popularity .

elbeicktalat commented 2 years ago

Hi @jonasfj, Thanks for the explanation, but why you don't include downloads count directly in the side bar without removing the popularity indication, I mean it's more easy to notes the difference between packages if you include this further.

kamel912 commented 2 years ago

This would be wonderful and may help us in choosing the best library for my need. I think there is another thing will give more help make a section for reviews

jonasfj commented 2 years ago

why you don't include downloads count directly in the side bar without removing the popularity indication

We have ongoing work to make new metrics. And we don't want to add/remove metrics left and right, when we can avoid it.

That said, it's possible we should look at how bad our current metrics are, and see if they can reasonably be exposed. I think they original decision not to expose them was because we thought they were skewed in many ways.

rrousselGit commented 2 years ago

The popularity score isn't bad per say. But it's not helpful for maintainers

I've been thinking for a while: if the problem is that some metrics are skewed, can't we make them visible only to the maintainers?
Like showing them in the admin page.

aymangithub commented 2 years ago

Yes it will be very nice if this feature added

topcheese commented 2 years ago

The popularity score isn't bad per say. But it's not helpful for maintainers

Why would it not be helpful to a maintainer to know that their package is popular or not? The amount of downloads also probably includes a bunch of old unmaintained libraries, that are not as popular as the newer ones with less downloads.

I think this false because we basically talking about the same thing. I think a popularity score can help keep it lively and fresh. It's still based on downloads.

rrousselGit commented 2 years ago

Why would it not be helpful to a maintainer to know that their package is popular or not?

Maintainers don't need pub.dev to know if their package is popular or not, as they have other metrics to know that (like github stars/issues, or how often the package is mentioned in articles/social medias)

Download count has other values besides knowing whether a package is popular or not. For example:

elbeicktalat commented 2 years ago

I've been thinking for a while: if the problem is that some metrics are skewed, can't we make them visible only to the maintainers?

I don't see why no make the downloads count available for both the maintainer and the consumer.

If the metrics are skewed will be also a problem for the maintainer.

topcheese commented 2 years ago 
* I'll know that _approximately_ half of Riverpod users use hooks_riverpod.

They both seem to be popular, and one less so. What would you really need to do with that piece of stat. As you've already mentioned, a maintainer should already know what they need to know, in order to make it more popular (increasing downloads). Besides, I wouldn't count on that as a usage stat just because it was downloaded. If that is the only metric you have, then it's another story, but do we don't always use every package we download. That seems like maybe a nice to have feature for those that feel they need it, but yes they can do better with the currently used metrics.

ueman commented 2 years ago

This is related to https://github.com/dart-lang/pub-dev/issues/2714

vaind commented 2 years ago

I'd say not related, but a duplicate of #2714

Blacktaler commented 3 months ago

All right but we should know what they mean exactly with exposing popularity?

As @maxzod said if they get the popularity from the downloads count it will be fine, but if they consider the search count or the click times so let me say it is useless.

They should explain what is exactly the popularity.

It is not count like that! Popularity is counted from how many projects use the package.

maheshmnj commented 3 months ago

It is not count like that! Popularity is counted from how many projects use the package.

Perhaps this issue is tracking the number of downloads and not dependents, If the latter then you can already get this number from a Github repo under contributions->dependents

image

Screenshot from this repo https://github.com/maheshmnj/searchfield

isoos commented 3 months ago

Popularity is counted from how many projects use the package. Perhaps this issue is tracking the number of downloads and not dependents

Note: the above portrayal of popularity score are not entirely correct. From the scoring help page: "Although this score is based on actual download counts, it compensates for automated tools such as continuous builds that fetch the package on each change request."

Source: https://pub.dev/help/scoring#popularity