PyPI 的下载统计中不再追踪元数据请求

2026年8月24日，我们启用了发布了配置文件的更改，导致 PyPI 的下载日志，使得只有针对实际分发构件的请求才会被计入下载量。只有以.whl、.tar.gz或.zip结尾的请求才会生成一条下载记录。

如今的统计更加准确，而基于PyPI 的 BigQuery 数据集的现有系统——例如pypistats.org——在未来将呈现出不同的变化趋势。

如果您维护的系统从公开数据集中读取这些数值，那么在2026年8月24日出现的断点是预期之中的，并且将是永久性的。

这一工作的开展离不开阿尔法-欧米茄一如既往的支持。

背景

日志由Fastly的边缘节点生成，传输至AWS S3存储桶，再由我们在Google Cloud中部署的线路运输函数进行解析与匿名化处理，最后发布到由Google托管的公开的BigQuery数据集中。

其他对象

PyPI为每个发布版本提供的所有内容都位于同一个/packages////路径前缀下。仅匹配该前缀会导致将对发布包中任意部分的获取都计为对该分发构件本身的下载。

• PEP 658的.metadata附带文件。（估计占比约40%）安装工具可能会获取这些元数据文件，从而读取wheel包的元数据而不下载wheel本身。此前每次元数据获取都被当作一次分发构件的下载记录下来。
• .asc格式的GPG签名。PyPI自2023年停止接受这些起不再计入此类签名的下载，但在此之前上传的签名仍可提供服务，只是不再纳入统计。
• .egg格式的上传则单独进行了2023年被淘汰处理。这些文件仍然可以下载，但均不计入下载量。
• 自2016年起在PEP 527框架下冻结上传的格式，如.exe、.msi和.rpm等，约占PyPI上文件总数的0.2%，现已不再计入下载量。

修正措施

截至2026年8月31日的60天窗口期内，PyPI全站每日下载量，来自pypistats.org。

调整前，每日总量在周末约为45亿次，工作日略高于70亿次。2026年8月24日之后，曲线出现明显下移。图表截取时，该窗口期的最后几天仍在数据归整过程中，因此应关注变化的趋势而非最终的数值。

对既有数据的影响

若比较2026年8月24日前后的下载量，数字将无法直接对应。该日期之后的统计数值更低，也更为准确。历史记录并未丢失——BigQuery中的旧有数据行保持不变，只是此前的统计口径宽于“有人下载了这个包”，而是统计“有人从PyPI下载了某个特定文件”。

目前大多数使用该数据集的用户并未按文件扩展名进行筛选，这导致单个包的下载量被高估。

不过，如果您希望自行查询数据，可以通过编写SQL语句来区分某个项目的分发构件下载与其他类型的下载。类似如下：

SELECT  DATE(timestamp) AS download_date,  COUNT(*) AS all_objects,  COUNTIF(REGEXP_CONTAINS(file.filename, r'\.(whl|tar\.gz|zip)
  
  




)) AS distributions_only,  COUNT(*) - COUNTIF(REGEXP_CONTAINS(file.filename, r'\.(whl|tar\.gz|zip)
  
  




)) AS others,  ROUND(100 * (COUNT(*) - COUNTIF(REGEXP_CONTAINS(file.filename, r'\.(whl|tar\.gz|zip)
  
  




))) / COUNT(*), 1) AS others_pct FROM `bigquery-public-data.pypi.file_downloads` WHERE project = 'urllib3'  AND timestamp >= TIMESTAMP('2026-08-18')  AND timestamp < TIMESTAMP('2026-08-26') GROUP BY download_date ORDER BY download_date 

结果如下：

对于本次查询所选的时间范围及项目而言，约39%的下载记录并非针对实际的分发构件。

下载量并非流行度指标

下载量的统计本就颇为棘手，也不应将其作为软件重要性或受欢迎程度的替代指标。下载量往往受到代理或缓存配置不当、持续集成系统失控，以及各类软件相关问题的驱动。

甚至还有人为地抬高这些数字的情况。

此次调整消除了一个潜在的混淆与误读来源，但这并不意味着下载量能够准确反映使用某软件包的人数。

后续工作：范围请求

当前，HTTP响应码206 Partial Content与200 OK的计数方式完全相同。即使只是从wheel包中读取两个字节以检查其ZIP中央目录，也会被记录为对该整个wheel包的下载，与完整拉取全部30MB的客户端行为无异。

我们希望分别记录请求类型以及实际传输的字节数，以便分析时能够区分已提供服务的字节与被计入下载的请求。这项工作目前尚未排定具体时间表。

敬请关注https://github.com/pypi/linehaul-cloud-function/issues/232和https://github.com/pypi/linehaul-cloud-function/issues/252的相关进展。