冻结轮插件

使用锁文件创建冻结轮的Poetry插件。

为什么

当将Python应用程序的发布版本发布到PyPI时，一个常见的问题是所指定的依赖项是否会随着时间的推移继续工作。这往往是由于多种原因造成的，如依赖项指定不当、不遵守语义版本规则，或依赖项的发布管理不当。这导致一个现实情况是，安装较旧版本的程序很可能无法正常工作，因为底层依赖图已发生变化。

依赖项生态系统既复杂又脆弱。出现锁文件以确保可重复性，既证明了问题，也提供了一种解决方案。然而，当我们在打包生态系统中发布时，我们使用的是非冻结的依赖项规范，而不是锁文件。这意味着用于生成和验证发布的测试管道针对的是锁文件，但发布工件与锁文件内容分离，并从发布的那一刻起开始出现差异。

各种语言包分发渠道（npm、pypi、rubygems等）用于两种不同的主要分发目的，即用于库和应用程序。一般来说，对于库而言，现有的行为是合理的。库在其自身依赖上应该相对宽松，以免与依赖于它们的库产生冲突，并且最好由最小依赖图组成。但对于应用程序的分发，可重复和可验证的安装是基本目标，可能具有大型依赖图。使用冻结依赖图而不是版本规格是确保随时间重复安装的唯一方法。从根本上讲，这两种不同的分发目的有不同的受众，即库有开发者和应用程序作为消费者，应用程序有用户作为消费者。

什么是

一个构建后/发布前命令，用于创建具有冻结依赖的wheel。基本上，我们更新wheel元数据中的Requires-Dist，用基于poetry lock信息的版本信息替换基于pyproject.toml的版本规格，以使用冻结（即==版本）的规格。

注意，我们无法使用poetry来发布冻结wheel，因为它使用pyproject.toml中的元数据而不是冻结wheel的元数据。

可选依赖项

冻结wheel元数据将包含Provides-Extra条目，用于任何额外/可选依赖项。冻结Requires-Dist行将指定extra名称，用于仅出现在可选/额外依赖图中的包。

如果某个包同时作为嵌套的“主”依赖项和“额外”依赖项出现，其冻结wheel中的Requires-Dist条目不会指定额外名称。

为了将此行为与poetry的export插件相关联，这两个流程应该导致相同的安装包集

# Export Flow
poetry export -f requirements.txt > requirements.txt && pip install -r requirements.txt

# Freeze-wheel Flow
poetry build && poetry freeze-wheel && pip install my_frozen_wheel

引入额外依赖项

# Export Flow
poetry export --extras gcp -f requirements.txt && pip install -r requirements.txt

# Freeze-wheel Flow
poetry build && poetry freeze-wheel && pip install my_frozen_wheel[gcp]

不同之处在于何时选择安装哪些额外依赖项 - export在冻结时执行。 freeze-wheel在冻结时嵌入额外上下文，但将实际的额外选择推迟到安装时间。

用法

# install plugin
poetry self add poetry-plugin-freeze

# build per normal
poetry build

# add freeze step
poetry freeze-wheel

# avoid freezing specific packages
poetry freeze-wheel --exclude boto3 -e attrs

# Note we can't use poetry to publish because it uses metadata from pyproject.toml instead
# of frozen wheel metadata.

# publish per normal
twine upload dist/*.whl

单一代码库支持

为了支持由多个库/应用程序组成的单一代码库，在创建冻结wheel时，可以可选地使用路径指定的主组依赖项来替换它们的发布工件版本。

这假设自动化运行构建和发布各种子包，例如通常通过make或just。