PDM 的内部实现(2)

这篇文章将会介绍 PDM 的 lock 策略，基于当前最新版本 2.13。英文版由 LLM 辅助翻译。

PDM 是如何解析依赖的？

PDM 底层是用的一个纯 Python 实现的 PubGrub 解析算法，Resolvelib。若用通俗的语言解释，它的解析过程大致如下：

1. 选择一个未解析的依赖，获取它的所有版本的列表
2. 从最新版本开始尝试，获取这个版本的依赖
3. 检查这个版本的依赖与已解析的依赖是否有冲突
4. 若有冲突，尝试下一个版本
5. 若无冲突，将这个依赖的版本加入结果中
6. 若尝试过所有版本都无法解析，回溯到上个确定结果的依赖，尝试下一个版本
7. 最终所有依赖都解析完成，得到一个满足所有依赖的版本列表

解析完成以后，PDM 就会将结果写到 pdm.lock 文件中，这个文件除了包含所有依赖的版本信息，还包含了一些其他元数据。

条件依赖

有时我们需要根据不同的条件安装不同的包版本，这会利用 Marker，例如：

pytest >= 7.0; python_version >= "3.6"
pytest < 7.0; python_version < "3.6"

但是 PDM 现在暂时不支持解析这种条件依赖，原因是 PDM 的依赖解析器实现会把包名作为解集中的 key，换句话说，每个包在解集中有且只有一个确定的版本。不得不承认，这确实是 PDM 的一大缺陷，欢迎大家贡献代码来解决这个问题。

Lock 文件的元数据

pdm.lock 文件是一个 TOML 格式的文件，在它的 [metadata] 表中包含了一些元数据，包括：

[metadata]
groups = ["default", "all", "doc", "pytest", "test", "tox", "workflow"]
strategy = ["cross_platform", "inherit_metadata"]
lock_version = "4.4.1"
content_hash = "sha256:13270582f610302a77a5e1fef2192e1a65f5b6202cf15aedf12bf799de8de45c"

lock_version

这是一个三位的版本号，标明这个 lock 文件的兼容情况。第一位表示向后不兼容的改动，第二位表示向后兼容但向前不兼容的改动，第三位表示向前向后都兼容的改动。

比如说，假如当前 lock 文件的版本是 4.4.2，那么：

• 支持读取的版本有：4.3.0, 4.4.0, 4.4.3
• 不能读取的版本有：5.1.0, 3.0.0

每当更新 lock 文件时，PDM 会把当前的 lock 版本写入文件中。通过这个版本号，PDM 就可以决定是否应该尝试读取这个 lock 文件，或是提示用户重新生成 lock 文件。

groups

记录了这个 lock 文件是从哪些依赖分组生成的，列表中的每个值都对应了 pyproject.toml 中 optional-dependencies 或 dev-dependencies 的一个分组。 当依赖解析完成时，这些分组就会被记录在 lock 文件中，安装时，PDM 会检查你要求安装的分组是否包含其中。

content_hash

因为 lock 文件对应了一组初始输入，即从哪些依赖解析生成。在 PDM 中，这个输入就是 pyproject.toml 中写的依赖信息，content_hash 就是从这些内容计算出来的一个 sha256 值，当你的 pyproject.toml 发生变化，PDM 就会重新计算这个值，如果发现与 lock 文件中的值不一致，就会为你更新 lock 文件，并把新的 content_hash 写入其中。

Lock 策略

[metadata] 表中的 strategy 字段就记录了当前 lock 文件的策略，用来控制依赖解析的过程。

cross_platform

默认启用，PDM 会将所有平台的文件都写入 Lock 文件中，详见上篇文章。但有时我们不得不使用当前环境的 Lock，一大原因是某些包在不同平台发布的包有着完成不同的依赖列表，这样会使得跨平台锁产生错误的结果。在 PDM 中，如果要禁用一个 Lock 策略，只需要：

pdm lock --strategy=no_cross_platform

这条命令会取消 cross_platform 策略，已使用的其他策略不会被影响。

static_urls

默认情况下，[[package]] 的 files 字段中只会记录包文件的文件名，而不包含 URL。这样做的好处是用户可以自由切换到其他 PyPI 的镜像源，PDM 安装时只会检查下载的文件名包含在 Lock 文件中。而如果启用了 static_urls 策略，PDM 会记录包文件的 URL，安装时就会直接通过这些 URL 下载安装包。这样也可以方便一些安全审计工具检查包的来源。

inherit_metadata

默认启用，PDM 会尝试为每个包计算它的最终 Marker（详见 上篇文章）。这样的好处是，安装时 PDM 只需要 pdm.lock 这一个数据来源，并且遍历 lock 文件和求值 Markers 这个过程使用 Python 标准库¹就可以完成，不需要依赖 PDM 的其他组件。如果禁用这个策略，Marker 将不会记录在包中，这样 lock 文件中记录的信息就不足以让安装器决定是否安装这个包，安装过程会有些许变化。PDM 会通过要求安装和依赖列表，和 Lock 文件中的依赖信息，运行一次依赖解析过程，来取得最终需要安装的包版本的列表。

direct_minimal_versions

默认情况下，解析依赖时会从最新版本开始尝试，这样得到的 lock 结果通常包含了尽可能新的包版本。但有时为了测试库的兼容性，我们会希望看到它是否能在指定的最小依赖版本下工作。启用这个策略后，PDM 会尝试从最小版本开始解析依赖，得到的 lock 文件中的版本号就是最小版本的依赖。

--exclude-newer DATE

除了上述策略之外，PDM lock 还支持一个一次性选项 --exclude-newer。这个选项的作用有点类似于时光机，当指定了一个时间或日期之后，PDM 解析依赖时会跳过那些晚于这个时间点上传的包版本。使用这个选项可以让 lock 文件是可复现的。需要注意的是，包的上传时间需要 PyPI 源的支持，它必须实现了 PEP 700，否则，这个包会被认为不满足条件并会被忽略。

更新策略

在你尝试更新 lock 文件中的包版本时，PDM 也提供了不同的更新策略，这些策略可以通过 --update-* 选项来指定，pdm add，pdm lock，pdm update 均支持这组选项。

• --update-all：更新所有包（直接依赖+间接依赖）到最新版本，也就是完全忽略 lock 文件中的版本信息
• --update-reuse：只更新直接依赖的版本，复用 lock 文件中的间接依赖版本
• --update-eager：更新指定依赖及其间接依赖到最新版本，复用 lock 文件中的其他依赖版本
• --update-reuse-installed： 尽可能复用当前已安装的版本

更新依赖版本时，仍然会尊重 pyproject.toml 中指定的版本范围，这个行为可以通过 --unconstrained 选项关闭，即取消版本范围的限制。

到此为止，我们介绍了围绕 PDM 的 lock 文件的一系列功能和背后的逻辑，希望这些信息能帮助你更好地理解 PDM 的工作原理。