安装 wheel ‘distribution-1.0-py32-none-any.whl’

Wheel 安装从概念上讲包括两个阶段

• 解压。
  1. 解析 distribution-1.0.dist-info/WHEEL。
  2. 检查安装程序是否与 Wheel-Version 兼容。如果次要版本更大则发出警告，如果主要版本更大则中止。
  3. 如果 Root-Is-Purelib == ‘true’，则将归档文件解压到 purelib（site-packages）。
  4. 否则将归档文件解压到 platlib（site-packages）。
• 分发。
  1. 解压后的归档文件包括 distribution-1.0.dist-info/ 和（如果有数据）distribution-1.0.data/。
  2. 将 distribution-1.0.data/ 的每个子树移动到其目标路径。 distribution-1.0.data/ 的每个子目录都是目标目录字典中的一个键，例如 distribution-1.0.data/(purelib|platlib|headers|scripts|data)。
  3. 更新以 #!python 开头的脚本以指向正确的解释器。（注意：Python 脚本通常由包元数据处理，而不是逐字包含在 wheel 中。）
  4. 使用已安装的路径更新 distribution-1.0.dist.info/RECORD。
  5. 如果为空，则删除 distribution-1.0.data 目录。
  6. 编译任何已安装的 .py 到 .pyc。（卸载程序应该足够智能，即使 .pyc 未在 RECORD 中提及，也要将其删除。）

在实践中，安装程序通常会直接从归档文件中提取文件到其目标位置，而不会写入临时 distribution-1.0.data/ 目录。

文件格式

re.sub("[^\w\d.]+", "_", distribution, re.UNICODE)

distribution-1.0.dist-info/

distribution-1.0.data/

{
    'bindir': '$eprefix/bin',
    'sbindir': '$eprefix/sbin',
    'libexecdir': '$eprefix/libexec',
    'sysconfdir': '$prefix/etc',
    'sharedstatedir': '$prefix/com',
    'localstatedir': '$prefix/var',
    'libdir': '$eprefix/lib',
    'static_libdir': r'$prefix/lib',
    'includedir': '$prefix/include',
    'datarootdir': '$prefix/share',
    'datadir': '$datarootdir',
    'mandir': '$datarootdir/man',
    'infodir': '$datarootdir/info',
    'localedir': '$datarootdir/locale',
    'docdir': '$datarootdir/doc/$dist_name',
    'htmldir': '$docdir',
    'dvidir': '$docdir',
    'psdir': '$docdir',
    'pdfdir': '$docdir',
    'pkgdatadir': '$datadir/$dist_name'
}

Install-Paths-To: wheel/_paths.py
Install-Paths-To: wheel/_paths.json

data='../wheel-0.26.0.dev1.data/data'
headers='../wheel-0.26.0.dev1.data/headers'
platlib='../wheel-0.26.0.dev1.data/platlib'
purelib='../wheel-0.26.0.dev1.data/purelib'
scripts='../wheel-0.26.0.dev1.data/scripts'
# ...

{ "data": "../wheel-0.26.0.dev1.data/data", ... }

签名的 wheel 文件

Wheel 文件包含扩展的 RECORD，可以启用数字签名。 PEP 376 的 RECORD 已更改为包含安全哈希 digestname=urlsafe_b64encode_nopad(digest)（不带尾随 = 字符的 urlsafe base64 编码）作为第二列，而不是 md5sum。所有可能的条目都已哈希，包括任何生成的文件（例如 .pyc 文件），但不包括 RECORD 本身（因为它不能包含自身的哈希值）。例如

file.py,sha256=AVTFPZpEKzuHr7OvQZmhaU3LvwKz06AJw8mT\_pNh2yI,3144
distribution-1.0.dist-info/RECORD,,

签名文件 RECORD.jws 和 RECORD.p7s 在 RECORD 中根本没有提及，因为它们只能在生成 RECORD 后添加。归档文件中的所有其他文件都必须在 RECORD 中具有正确的哈希值，否则安装将失败。

如果使用 JSON Web 签名，则一个或多个 JSON Web 签名 JSON 序列化 (JWS-JS) 签名将存储在 RECORD 旁边的 RECORD.jws 文件中。JWS 用于通过将 RECORD 的 SHA-256 哈希值作为签名的 JSON 有效负载来签署 RECORD。

{ "hash": "sha256=ADD-r2urObZHcxBW3Cr-vDCu5RJwT4CaRTHiFmbcIYY" }

（哈希值与 RECORD 中使用的格式相同。）

如果使用 RECORD.p7s，则它必须包含 RECORD 的分离 S/MIME 格式签名。

wheel 安装程序不需要理解数字签名，但*必须*验证 RECORD 中的哈希值是否与提取的文件内容匹配。当安装程序根据 RECORD 检查文件哈希值时，单独的签名检查程序只需要确定 RECORD 是否与签名匹配即可。

参见

• RFC 7515
• https://datatracker.ietf.org/doc/html/draft-jones-jose-jws-json-serialization.html
• RFC 7517
• https://datatracker.ietf.org/doc/html/draft-jones-jose-json-private-key.html

与 .egg 的比较

1. Wheel 是一种安装格式；egg 是可导入的。Wheel 归档文件不需要包含 .pyc，并且与特定 Python 版本或实现的关联性较小。Wheel 可以安装使用早期版本的 Python 构建的（纯 Python）包，因此您不必总是等待打包程序赶上进度。
2. Wheel 使用 .dist-info 目录；egg 使用 .egg-info。Wheel 与 Python 打包的新世界及其带来的新概念兼容。
3. Wheel 具有更丰富的文件名约定，适用于当今的多实现世界。单个 wheel 归档文件可以指示其与许多 Python 语言版本和实现、ABI 以及系统架构的兼容性。从历史上看，ABI 是特定于 CPython 版本的，wheel 已准备好用于稳定的 ABI。
4. Wheel 是无损的。第一个 wheel 实现 bdist_wheel 始终生成 egg-info，然后将其转换为 .whl。也可以转换现有的 egg 和 bdist_wininst 发行版。
5. Wheel 是带版本号的。每个 wheel 文件都包含 wheel 规范的版本以及打包它的实现。希望下一次迁移只需迁移到 Wheel 2.0 即可。
6. Wheel 是对其他 Python 的引用。

Wheel 定义了一个 .data 目录。我应该把所有数据都放在那里吗？

本规范对如何组织代码没有意见。.data 目录只是用于任何通常不安装在 site-packages 或 PYTHONPATH 上的文件的位置。换句话说，即使*这些*文件通常不会分发在 wheel 的 .data 目录中，您也可以继续使用 pkgutil.get_data(package, resource)。

为什么 wheel 包含附加签名？

附加签名比分离签名更方便，因为它们与归档文件一起传输。由于仅对单个文件进行签名，因此可以重新压缩归档文件而不会使签名失效，或者可以验证单个文件而无需下载整个归档文件。

为什么 wheel 允许 JWS 签名？

JWS 所属的 JOSE 规范旨在易于实现，这也是 wheel 的主要设计目标之一。JWS 生成了一个有用的、简洁的纯 Python 实现。

为什么 wheel 也允许 S/MIME 签名？

对于需要或希望使用现有公钥基础设施的用户，允许使用 S/MIME 签名。

已签名的包只是安全包更新系统中的一个基本构建块。Wheel 仅提供构建块。

“purelib” 和 “platlib” 有什么区别？

Wheel 保留了“purelib”与“platlib”的区别，这在某些平台上非常重要。例如，Fedora 将纯 Python 包安装到‘/usr/lib/pythonX.Y/site-packages’，并将平台相关的包安装到‘/usr/lib64/pythonX.Y/site-packages’。

一个“Root-Is-Purelib: false”的 wheel，其所有文件都在 {name}-{version}.data/purelib 中，等效于一个“Root-Is-Purelib: true”的 wheel，其文件在根目录中，并且在“purelib”和“platlib”类别中都存在文件是合法的。

实际上，一个 wheel 应该只有一个“purelib”或“platlib”，具体取决于它是否为纯 Python，并且这些文件应该位于根目录中，并为“Root-is-purelib”设置适当的值。

是否可以从 wheel 文件中直接导入 Python 代码？

从技术上讲，由于支持通过简单提取进行安装以及使用与 zipimport 兼容的归档格式的组合，wheel 文件的一个子集*确实*支持直接放置在 sys.path 上。但是，虽然此行为是格式设计的自然结果，但通常不建议实际依赖它。

首先，wheel*确实*主要设计为一种分发格式，因此跳过安装步骤也意味着故意避免对任何依赖于假设完整安装的功能（例如，能够使用标准工具（如 pip 和 virtualenv）以一种可以正确跟踪以进行审计和安全更新目的的方式捕获和管理依赖项，或通过在适当的位置发布头文件来与 C 扩展的标准构建机制完全集成）。

其次，虽然一些 Python 软件被编写为支持直接从 zip 档案运行，但代码通常还是假设它已经被完全安装。当尝试从 zip 档案运行软件时违反了这个假设，故障通常会很模糊且难以诊断（尤其是在第三方库中发生时）。导致此问题最常见的两个来源是：CPython **不支持**从 zip 档案导入 C 扩展（因为在任何平台上动态加载机制都不直接支持这样做），以及从 zip 档案运行时，__file__ 属性不再引用普通的 文件系统路径，而是包含文件系统上 zip 档案的位置和档案内模块的相对路径的组合路径。即使软件在内部正确地使用了抽象资源 API，与外部组件的交互可能仍然需要实际磁盘文件的存在。

就像元类、猴子补丁和元路径导入器一样，如果您不确定自己是否需要利用此功能，那么您几乎肯定不需要它。如果您确实决定使用它，请注意，许多项目将要求在接受其为真正的错误之前，使用完全安装的软件包重现错误。