pub-dev
pub-dev copied to clipboard
dart-lang
Proposal: Show Weekly and Total Downloads of package
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.
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!
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
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'"
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
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.
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.
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?
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.
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.
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 .
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.
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
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.
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.
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.
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:
- we can have the download count per version. So it'd be a mean to know how many users migrated to newer versions.
- although not perfect, it is an indicator of the number of people who use a package.
For example I'm wondering how many users of Riverpod use hooks_riverpod instead of flutter_riverpod. They respectively have a popularity of 97% and 98%, but that's unhelpful.
With download counts, if hooks_riverpod is downloaded 1k times and flutter_riverpod is downloaded 2k times, then I'll know that approximately half of Riverpod users use hooks_riverpod.
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.
* 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.
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.
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
Screenshot from this repo https://github.com/maheshmnj/searchfield
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
