I don't really mean to stir the pot, because I mostly believe download counts are useless....
Even so, I would point out that "possibly" slightly more useful would be install counts. However this would require that we configure CPAN reporter to be able to submit install reports (success/failure) via LWP/Mechanize. For the firewall challenged, this is the only viable option for us out there. Todd On Sat, Jul 5, 2008 at 2:55 PM, Eric Wilhelm <[EMAIL PROTECTED]> wrote: > # from Aristotle Pagaltzis > # on Friday 04 July 2008 22:38: > >>* Eric Wilhelm <[EMAIL PROTECTED]> [2008-07-04 10:25]: >>> Assuming that we could obtain download counts (which we can't) >> >>...Case in point: I keep my own minicpan mirror... > > So? I said "(which we can't)" to convey that counting downloads is > impossible -- it cannot be done. I went on to briefly explain that it > is also futile, which you have also done. Now that we've covered that > twice, we can move on? > > Getting opt-in counts of usage via dependency scanning: > > grep -h '^use ' $(echo $PATH | sed 's/:/\n/g' | sort -u | \ > sed 's/$/\/*/') | perl -pe 's/^use //; s/(;| |\().*//' | sort -u > > The above pipeline is a very dumb scan [1], but already gathers useful > information. Now take that output and prune [3] every module which is > not found in your ~/.cpanplus/02-packages.details.txt.gz [2] and post > the resulting list [4]. > > Now, of course this is all fun and interesting, but it does $me very > little good to tell $you what modules I'm running. So, even if $you > worked through all of the caveats in [1], why would $me bother to > install it and setup a cron job to post the results? Thus, I think the > incentive has to come in the form of something $me can use to improve > $me's code/process/etc. For example, a local DB holding all of that > info and some reports -- which is where the source file and frequency > count become important. > > > Footnotes: > [1] It should skip missing directories, has obvious static scanning > problems (re eval, pod, quoting, &c) with '^use ', misses require()s, > and anything after a semicolon. The -h option and final `sort -u` also > drops the source file and frequency data. And there's nothing in that > grep which says it is a perl file. Further, this skips cgi-bin, sbin, > and doesn't even look for library trees. > > [2] The 02packages.details.txt.gz can be found in your mirror's > "modules/" directory, but of course if you have the module installed via > CPAN(PLUS), your local copy is up-to-date enough to list it. > > [3] http://scratchcomputing.com/tmp/module_is_shipped.pl > > [4] http://scratchcomputing.com/tmp/modules_in_bin.txt [5] > > [5] I see 'the' in there, and yes Ingy published a "the.pm", but no I > don't have it installed. See [1]. > > --Eric > -- > "It is impossible to make anything foolproof because fools are so > ingenious." > --Murphy's Second Corollary > --------------------------------------------------- > http://scratchcomputing.com > --------------------------------------------------- > > -- Todd Rinaldo [EMAIL PROTECTED]
