我在2个月前第一次放a package on PyPi,并且从那以后做了一些版本更新。本周我注意到了下载计数记录,并惊讶地看到它被下载了数百次。在接下来的几天里,我更惊讶的是,即使这是一个利基统计测试工具箱,下载次数有时会增加数百每天。特别是,旧版本的软件包将继续下载,有时以比最新版本更高的速度下载。
这里发生了什么?
PyPi的下载计数是否存在错误,或者是否有大量抓取工具抓取开源代码(就像我的一样)?
答案 0 :(得分:73)
这是一个古老的问题,但是我注意到我在PyPI上有一个包,并进一步调查。事实证明,PyPI保持了相当详细的download statistics,包括(显然略微匿名化)用户代理。从那以后,很明显大多数人下载我的软件包都是“z3c.pypimirror / 1.0.15.1”和“pep381client / 1.5”之类的东西。 (PEP 381描述了PyPI的镜像基础结构。)
我写了a quick script来计算所有内容,首先包括所有这些,然后遗漏最明显的机器人,结果是字面上99%我的下载活动软件包是由mirrorbots引起的:总共下载了14,335次,相比之下只有146次下载过滤机器人。而这只是遗漏了非常明显的一些,所以它可能仍然过高估计。
看起来PyPI需要镜像的主要原因是因为它有它们。
答案 1 :(得分:11)
从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](如分发,点子,请求,paramiko,lxml,boto,paramike,redis等)你真正需要的至少从可访问的角度来反映。想象一下当pip install NeedThisPackage
失败时用户做了什么:等待?公司范围的PyPI镜像也很常见,作为其他不可路由的网络的代理。最后不要忘记通过virtualenv和朋友启用的精彩多版本检查。这些都是IMO合法的,可能是包的使用......
最后,你永远不知道代理真正对下载的软件包做了什么:N个用户真的使用它或者只是下次覆盖它...毕竟,IMHO软件包作者应该关注数量和使用性质,比纯潜在用户数 ;-)
参考:所估计的数字来自https://pypi.python.org/pypi(29303包)和http://pypi-ranking.info/week(对于每周数字,请求2013-03-23)。
答案 2 :(得分:10)
你还必须考虑到virtualenv越来越受欢迎了。如果您的软件包类似于人们在许多项目中使用的核心库,他们通常会多次下载它。
考虑一个用户有5个项目,他使用你的包,每个项目都有自己的virtualenv。使用pip来满足要求,您的包已经以这种方式下载了5次。然后,可以在不同的机器上设置这些项目,例如工作,家庭和膝上型计算机,此外,在Web应用程序的情况下可能存在升级和实时服务器。总结一下,你最终只能由一个人下载很多次。
只是一个想法......也许你的包装很好。 ;)
答案 3 :(得分:2)
假设:像Travis CI和Appveyor这样的CI工具也有相当多的贡献。这可能意味着每个提交/推送都会导致包的构建以及在requirements.txt
中安装所有内容