PyPi 的下载计数似乎不切实际

我把 一个关于 PyPi 的包裹第一次 ~ 2个月前，并作出了一些版本的更新，从那时起。我注意到这周的下载次数记录，并惊讶地发现它已经被下载了数百次。在接下来的几天里，我更惊讶地看到下载数量有时会增加数百个 每天，尽管这是一个利基统计测试工具箱。特别是，旧版本的软件包仍在继续下载，有时下载速度比最新版本更快。

这是怎么回事？

在 PyPi 的下载计数中是否存在 bug，或者是否有大量抓取开源代码的爬虫(就像我的一样) ？

10725 次浏览
小开

您还必须考虑到，viralenv 正变得越来越流行。如果您的软件包类似于人们在许多项目中使用的核心库，那么他们通常会多次下载它。

假设一个用户有5个项目，在这些项目中，他使用您的软件包，并且每个项目都生活在自己的 viralenv 中。使用 pip 来满足需求，您的软件包已经通过这种方式下载了5次。然后，这些项目可能会设置在不同的机器上，如工作，家庭和笔记本电脑，此外，还可能有一个登台和一个活动服务器的情况下，一个 Web 应用程序。总而言之，您最终会得到一个人的许多下载。

只是一个想法... 也许你的包裹只是好。 ;)

小开
最佳答案

在这一点上，这是一个老问题，但是我注意到了关于我在 PyPI 上的一个包的同样的事情，并进一步研究了它。原来 PyPI 保留了相当详细的 下载统计数字，包括(显然略微匿名的)用户代理。由此可见，大多数下载我的软件包的人都是像“ z3c.pypimror/1.0.15.1”和“ pep381client/1.5”这样的东西。(PEP 381描述了 PyPI 的镜像基础结构。)

我编写了 一个简短的剧本来统计所有数据，首先包括所有数据，然后忽略了最明显的机器人。结果发现，我软件包中的 99% 下载活动是由镜像机器人引起的: 总共有14,335次下载，相比之下，只有146次下载经过机器人过滤。这只是忽略了那些非常明显的因素，所以这可能仍然是一个高估。

看起来 PyPI 需要镜像的主要原因是因为它有镜像。

小开

首先是 Cairnarvon 的总结陈述:

“看起来 PyPI 需要镜像的主要原因是因为它有镜像。”

我会稍微修改一下:

它可能是更多的 方式 PyPI 实际工作，因此必须进行镜像，这可能会为 真的流量贡献一个额外的位(或两个: ——)。

目前，我认为您必须与主索引交互，以了解在存储库中更新什么。状态不能简单地通过某些公共可访问的文件夹层次结构上的时间戳进行访问。所以，坏消息是 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个包托管[ 1] ，其中一些包每周下载50.000到300.000次[ 2](比如 distribution，pip，request，parmiko，lxml，boto，parike，redis 等) ，那么至少从可访问性的角度来看，你确实需要镜像。想象一下当 pip install NeedThisPackage失败时用户会做什么: 等等？此外，公司范围内的 PyPI 镜像非常常见，它充当原本不可路由的网络的代理。最后，不要忘记通过 viralenv 和朋友启用的美妙的多版本检查。这些都是国际海事组织的合法和潜在的奇妙用途的包..。

最后，你永远不会知道代理 真的对下载的软件包做了什么: 有 N 个用户真正使用它或者下次只是覆盖它... 毕竟，IMHO 软件包的作者应该更关心 用途的数量和性质，而不是纯 潜在使用者人数; -)

参考: 估计数字来自 https://pypi.python.org/pypi(29303包)和 http://pypi-ranking.info/week(每周数字，请求2013-03-23)。

小开

假设: 像 Travis CI 和 Appveyor 这样的 CI 工具也做出了相当大的贡献。这可能意味着，每次提交/推送都会导致构建一个包，并安装 Requments.txt 中的所有内容


提交答案