Deployers¶
Deployers 是一种机制，用于方便地将文件从一个文件夹（通常是 Conan 缓存）复制到用户文件夹。虽然 Conan 提供了两个内置的 deployers（full_deploy 和 direct_deploy），但用户可以使用 conan config install 轻松管理自己的 deployers。
Deployers 在 generators 之前运行，并且可以更改目标文件夹。例如，如果 --deployer=full_deploy deployer 在 CMakeDeps 之前运行，那么由 CMakeDeps 生成的文件将指向 full_deploy deployer 在用户文件夹中创建的本地副本，而不是指向 Conan 缓存。通过提供多个 --deployer= 参数，可以指定多个 deployers，它们将按出现的顺序运行。
Deployers 可以是多配置的。为不同的 profiles 重复运行 conan install . --deployer=full_deploy 可以实现一个完全自包含的项目，包括所有工件、二进制文件和构建文件。该项目将完全独立于 Conan，并且不再需要 Conan 来进行构建。可以使用 --deployer-folder 参数按需更改 deployer 的基本输出文件夹路径。
内置 deployers¶
警告
内置 deployers 处于 **预览** 状态。有关更多信息，请参阅 Conan 稳定性 部分。
full_deploy¶
将每个依赖项的包文件夹复制到您的 recipe 的 output_folder 中，形成一个基于以下内容的子文件夹树：
构建上下文
依赖项名称和版本
构建类型
构建架构
然后，每个依赖项将位于类似这样的文件夹中：
[OUTPUT_FOLDER]/full_deploy/host/dep/0.1/Release/x86_64
在 为开发者创建 Conan 不可知的依赖项部署 中，可以找到 full_deploy deployer 用法的完整示例。
direct_deploy¶
与 full_deploy 相同，但仅处理您的 recipe 的 *直接* 依赖项。此 deployer 将以类似这样的树形文件夹输出您的依赖项：
[OUTPUT_FOLDER]/direct_deploy/dep
runtime_deploy¶
自 Conan 2.5.0 起新增
将所有共享库和可执行文件（如 .so、.dll 或 .dylib 文件）从依赖项复制到一个扁平的目录结构中。
自 Conan 2.20.0 起，子目录将被维护并按原样保留。文件仅在通过 cpp_info.bindirs 和 cpp_info.libdirs 配置正确指定后才包含在环境生成器中。
配置¶
当 conf tools.deployer:symlinks 被设置为 False 以禁用 deployers 复制符号链接时，full_deploy、direct_deploy 和 runtime_deploy 能够识别此设置。这对于不支持符号链接的系统可能很方便，因为部署包含符号链接的包可能会失败。
自定义 deployers¶
可以通过 conan config install 来管理自定义 deployers。在查找特定 deployer 时，Conan 将按以下顺序在以下位置查找 deployer：
绝对路径
相对于当前工作目录
在
[CONAN_HOME]/extensions/deployers文件夹中作为内置 deployers
Conan 将查找一个 deploy() 方法来调用每个已安装的文件。您的自定义 deployers 的函数签名应如下所示：
def deploy(graph, output_folder: str, **kwargs):
(请注意，参数是通过命名参数传递的，因此 graph 和 output_folder 名称都是必需的)
**kwargs 是必需的，即使未使用，因为未来的 Conan 版本可能会添加新参数，如果未定义 **kwargs，这些参数将导致中断。
您可以使用 graph.root.conanfile 访问您的 conanfile 对象。有关如何迭代其依赖项的信息，请参阅 ConanFile.dependencies。您的自定义 deployer 现在可以像内置 deployer 一样调用，使用它所在的文件名，在这种情况下是 conan install . --deployer=my_custom_deployer。请注意，提供 **.py** 扩展名是可选的。
有关如何实现自己的 deployers 的示例，请参阅 自定义 deployers 部分。