Download counts have (kind of) been re-enabled on PyPI. The new download counts work as so: * At the bottom of a detail page there is rolling tallies for the last day, the last week, and the last month[1] * The API exposes total download counts per file still. * The rolling counts update more or less in real time while the total counts in the API update hourly. * We no longer incorporate download counts from mirrors, making the mirroring infrastructure a tree and not a federation. [1] Only the last day is enabled currently, once more data is available the last week and last month will also be enabled. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On Thu, Jun 27, 2013 at 5:18 PM, Donald Stufft <donald@stufft.io> wrote:
Download counts have (kind of) been re-enabled on PyPI.
The new download counts work as so:
* At the bottom of a detail page there is rolling tallies for the last day, the last week, and the last month[1] * The API exposes total download counts per file still. * The rolling counts update more or less in real time while the total counts in the API update hourly. * We no longer incorporate download counts from mirrors, making the mirroring infrastructure a tree and not a federation.
Is there any plan for per-version/per-file stats? I notice that the current stat display is across all versions, which makes it harder to tell e.g. setuptools 0.7 uptake vs 0.6.
On Jun 27, 2013, at 11:24 PM, PJ Eby <pje@telecommunity.com> wrote:
On Thu, Jun 27, 2013 at 5:18 PM, Donald Stufft <donald@stufft.io> wrote:
Download counts have (kind of) been re-enabled on PyPI.
The new download counts work as so:
* At the bottom of a detail page there is rolling tallies for the last day, the last week, and the last month[1] * The API exposes total download counts per file still. * The rolling counts update more or less in real time while the total counts in the API update hourly. * We no longer incorporate download counts from mirrors, making the mirroring infrastructure a tree and not a federation.
Is there any plan for per-version/per-file stats? I notice that the current stat display is across all versions, which makes it harder to tell e.g. setuptools 0.7 uptake vs 0.6.
That information is available via the API in a total format (basically the old download formats). I think for someone evaluating the popularity of a package the new format is much more useful. Obviously there is more information that _could_ be displayed (with varying amounts of effort) but you run the risk of overwhelming the user with stats. There's a lot more I'd like to do in general statistics wise geared towards different targeted audiences. There aren't exact plans right now as there are more pressing concerns and it needs to be done in a way that tells a useful "story" without overwhelming people with numbers. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
Is there any plan for per-version/per-file stats? I notice that the current stat display is across all versions, which makes it harder to tell e.g. setuptools 0.7 uptake vs 0.6.
That information is available via the API in a total format (basically the
Donald Stufft <donald <at> stufft.io> writes: old download formats).
I think for someone evaluating the popularity of a package the new format
is much more useful. Obviously
there is more information that _could_ be displayed (with varying amounts of effort) but you run the risk of overwhelming the user with stats.
There's a lot more I'd like to do in general statistics wise geared towards different targeted audiences. There aren't exact plans right now as there are more pressing concerns and it needs to be done in a way that tells a useful "story" without overwhelming people with numbers.
Are you sure it doesn't "just work"? Vanity seems to work as expected now, I just cut a new release: aclark@Alexs-MacBook-Pro:~/ > vanity vanity vanity-1.0.zip 2011-04-14 980 vanity-1.1.0.zip 2011-10-26 771 vanity-1.1.1.zip 2011-10-28 744 vanity-1.1.2.zip 2011-10-28 775 vanity-1.2.0.tar.gz 2012-01-30 712 vanity-1.2.1.tar.gz 2012-02-16 761 vanity-1.2.2.zip 2012-07-31 474 vanity-1.2.3.zip 2012-08-08 523 vanity-1.2.4.zip 2013-02-19 249 vanity-1.2.5.zip 2013-03-18 252 vanity-2.0.0.zip 2013-05-26 3 vanity-2.0.1.zip 2013-05-27 0 vanity-2.0.2.zip 2013-05-27 2 vanity-2.0.3.zip 2013-06-28 0 ---------------------------------------------- vanity has been downloaded 6,246 times! aclark@Alexs-MacBook-Pro:~/ > vanity vanity==2.0.2 vanity-2.0.2.zip 2013-05-27 2 ------------------------------------------- vanity 2.0.2 has been downloaded 2 times! I don't necessarily care what is displayed on PyPI, as long as we have (roughly) the same functionality as before. Thanks for working on this!
On Jun 28, 2013, at 7:36 AM, Alex Clark <aclark@aclark.net> wrote:
Donald Stufft <donald <at> stufft.io> writes:
Is there any plan for per-version/per-file stats? I notice that the current stat display is across all versions, which makes it harder to tell e.g. setuptools 0.7 uptake vs 0.6.
That information is available via the API in a total format (basically the old download formats).
I think for someone evaluating the popularity of a package the new format is much more useful. Obviously there is more information that _could_ be displayed (with varying amounts of effort) but you run the risk of overwhelming the user with stats.
There's a lot more I'd like to do in general statistics wise geared towards different targeted audiences. There aren't exact plans right now as there are more pressing concerns and it needs to be done in a way that tells a useful "story" without overwhelming people with numbers.
Are you sure it doesn't "just work"? Vanity seems to work as expected now, I just cut a new release:
Yes the API contains the old numbers. (That is, they are updating, but it is by file totals). ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On Thu, Jun 27, 2013 at 17:18 -0400, Donald Stufft wrote:
Download counts have (kind of) been re-enabled on PyPI.
The new download counts work as so:
* At the bottom of a detail page there is rolling tallies for the last day, the last week, and the last month[1] * The API exposes total download counts per file still. * The rolling counts update more or less in real time while the total counts in the API update hourly. * We no longer incorporate download counts from mirrors, making the mirroring infrastructure a tree and not a federation.
[1] Only the last day is enabled currently, once more data is available the last week and last month will also be enabled.
haven't investigated much but FYI it appears to me that the download numbers are not accurate. Yesterday i downloaded a package myself three times alone from three different locations and the download number i see now is "2". And i am pretty sure i wasn't the only one doing a download. cheers, holger
----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
On Sat, Jun 29, 2013 at 12:51 +0000, Alex Clark wrote:
Yesterday i downloaded a package myself three times alone from three different locations and the download number i see now is "2". And i am
holger krekel <holger <at> merlinux.eu> writes: pretty sure i wasn't the only one doing a download.
What package?
I was using vanity (good name, btw :) and for example looking at devpi-0.9.tar.gz shows "0" downloads. Also, devpi-server saw a few hundred downloads per release before the CDN move and now shows up with "1" or so. Given that i just gave a training where a few people had it installed i am pretty sure that can't be. cheers, holger
participants (4)
-
Alex Clark -
Donald Stufft -
holger krekel -
PJ Eby