Is the download number real?

[Gnimuc]

CEnum.jl has 300k downloads in total and the download number of another Julia-C interop package Clang.jl increases at a rate of ~1k/month.

Given that Clang.jl is generally not being used as a dependency package, so those downloads should not come from CI triggers. And this package has very niche use cases, so I'm sure there are not so many active users that can trigger so many downloads.

That's why I suspect the number is actually wrong.

[AbhimanyuAryan]

@Gnimuc can you verify the numbers directly from https://julialang-logs.s3.amazonaws.com/public_outputs/current/package_requests_by_region_by_date.csv.gz ?? If they are same then it means that stats are wrong in original source

[Gnimuc]

This is the data for Clang.jl:

request_addrs	request_count
209	1563

I feel the number of request_addrs is closer to the fact. But request_count is something we currently show by PkgVizBoard.

[AbhimanyuAryan]

@Gnimuc so request_count from what start - end date?

[AbhimanyuAryan]

[Gnimuc]

@AbhimanyuAryan I only counted user downloads, I guess 1658 is the sum of request_count column in the CSV file.

[Gnimuc]

Do you think it's a good idea to add more filters(not just regions) to the UI?

[essenciary]

@Gnimuc What other filters do you have in mind?

We could extend by also showing request_addrs. It would be cool to plot both request_count and request_addrs on the same plots. We should also extend the API to include it and add the option to show it on badges.

[Gnimuc]

We could extend by also showing request_addrs. It would be cool to plot both request_count and request_addrs on the same plots. We should also extend the API to include it and add the option to show it on badges.

I think this is exactly what I want.

BTW, for client_type, I guess we should exclude those CI rows.