PyPi下载计数似乎是不现实的
我在第一次〜2个月前在PyPi上安装了一个软件包 ，并从那以后做了一些版本更新。 我注意到本周的下载计数logging，并惊讶地发现它已被下载数百次。 在接下来的几天中，即使这是一个利基统计testing工具箱，我也更惊讶地发现下载次数每天有几百次增加。 特别是，旧版本的软件包将继续下载，有时会比最新版本更高。
这里发生了什么？
PyPi的下载计数是否存在一个错误，或者是否有大量抓取开源代码的抓取工具？
在这一点上，这是一个古老的问题，但是我注意到关于PyPI的一个包，并进一步调查。 事实certificate，PyPI保持合理的详细下载统计 ，包括（显然稍微匿名）的用户代理。 从这一点上看，大多数下载我的软件包的人都是“z3c.pypimirror / 1.0.15.1”和“pep381client / 1.5”。 （PEP 381描述了PyPI的镜像基础结构。）
我写了一个快速脚本来整理所有的东西，首先包括所有这些，然后把最明显的机器人，而事实certificate，我的包的下载活动从字面上99％是由镜像机器人引起的：共14,335次下载只有146下载与机器人过滤。 而这只是把非常明显的那些遗漏掉了，所以它可能仍然是一个高估。
看起来PyPI需要镜像的主要原因是因为它有它们。
从Cairnarvon的总结陈述开始：
“看起来PyPI需要反映的主要原因是因为它有它们。”
我会稍微修改一下：
PyPI的实际工作方式可能更多，因此必须进行镜像，这可能会对实际stream量产生额外的影响（或两个:-)。
目前我认为你必须与主索引进行交互，以便知道你的仓库中要更新什么。 状态不能简单地通过一些可公开访问的文件夹层次上的时间戳来访问。 所以，不好的一点是，rsync是不合适的。 好的是，您可以通过JSON，OAuth，XML-RPC或HTTP接口与索引进行交谈。
对于XML-RPC：
$> python >>> import xmlrpclib >>> import pprint >>> client = xmlrpclib.ServerProxy('http://pypi.python.org/pypi') >>> client.package_releases('PartitionSets') ['0.1.1'] 对于JSON例如：
$> curl https://pypi.python.org/pypi/PartitionSets/0.1.1/json
如果有约。 30.000个软件包托pipe[ 1 ]，其中一些软件每周下载50,000到300,000次[ 2 ]（比如分发，点击，请求，paramiko，lxml，boto，paramike，redis等），至less从一个可访问性的angular度来看， 试想一下，当pip install NeedThisPackage失败时用户会做什么： 等等 ？ 此外，公司范围内的PyPI镜像作为其他无法转发的networking的代理也相当普遍。 最后不要忘记通过virtualenv和朋友启用的精彩的多版本检查。 这些都是国际海事组织合法的，可能是美妙的包装使用
最后，你永远不会知道一个代理真正用下载的软件包：有N个用户真正使用它或下次只是覆盖它…毕竟，恕我直通包的作者应该更多地关心使用的数量和性质 ，而不是纯粹的潜在用户数量 😉
参考：估计数字是从https://pypi.python.org/pypi（29303包）和http://pypi-ranking.info/week （每周数字，请求2013-03-23）。
你还必须考虑到virtualenv越来越受欢迎。 如果你的软件包就像人们在许多项目中使用的核心库一样，他们通常会多次下载它。
考虑一个用户有5个项目，他使用你的软件包，并且每个用户都拥有自己的virtualenv。 使用pip来满足要求，你的包已经下载了5次。 然后，这些项目可能设置在不同的机器，如工作，家庭和笔记本电脑，此外，可能会有一个登台和现场服务器的情况下，一个Web应用程序。 综上所述，最终你会得到一个人的许多下载。
只是一个想法…也许你的包很简单。 ;）
假设：像Travis CI和Appveyor这样的CI工具也有相当的贡献。 这可能意味着每个提交/推送都会导致构build一个包，并将所有内容安装在requirements.txt中
PyPI-Stats.com的结果看起来很合理。
