本地配方索引仓库¶
本地配方索引（Local Recipes Index）是 Conan 中引入的一种实验性仓库类型，旨在增强 C/C++ 包配方管理的灵活性。这种仓库类型允许用户将本地目录用作 Conan 远程仓库，其中目录结构与 conan-center-index GitHub 仓库的结构相对应。
此设置对于以下情况特别有用：
从私有 conan-center-index 分支构建二进制文件。
分享您自己的某些库或工具的配方，这些配方由于许可限制或专有性质不适合 ConanCenter。请查阅文档的专门部分，了解如何将它用于此目的：本地配方索引仓库。
从私有 conan-center-index 分支构建二进制文件¶
正如我们已经在Conan DevOps 指南的上一节中介绍的那样，一些组织，特别是大型企业，更喜欢不使用从互联网下载的二进制文件。相反，他们使用 conan-center-index 配方在内部构建自己的二进制文件。这些组织通常需要自定义这些配方以满足独特的、不适用于更广泛社区的需求，使得此类贡献不适合上游仓库。
local-recipes-index 允许用户维护一个与 conan-center-index GitHub 仓库结构相同的本地文件夹，并将其用作包配方的来源。这种新型仓库仅包含配方，因此需要在使用该包的每台机器上从源代码构建包二进制文件。为了在团队之间共享二进制文件，我们仍然建议将 Conan 远程服务器（如 Artifactory）用于生产目的。
local-recipes-index 仓库允许您轻松地从 conan-center-index 的分支构建二进制文件，然后将其托管在像 Artifactory 这样的 Conan 远程仓库上。与上一节中解释的过程主要区别在于，它能够立即测试多个本地更改，而无需在每次修改配方时进行导出。
请注意，在这种情况下，出于以下几个原因，不建议将 ConanCenter 的二进制文件与本地构建的二进制文件混合使用：
二进制兼容性：ConanCenter CI 和用户 CI 之间的设置可能存在细微差异。保持所有二进制文件设置的一致性可以缓解一些问题。
完全控制构建：自己构建所有二进制文件可确保您对编译环境和依赖版本拥有完全控制。
相反，建议您从分支构建所有直接和传递依赖项。首先，移除上游 ConanCenter，因为它将不再使用，所有内容都将来自我们自己的分支。
$ conan remote remove conancenter
然后我们将克隆我们的分支（在本例中，我们直接克隆上游用于演示目的，但您会克隆您自己的分支）：
$ git clone https://github.com/conan-io/conan-center-index
将其添加为我们的 mycenter 远程仓库：
# Add the mycenter remote pointing to the local folder
$ conan remote add mycenter ./conan-center-index
就是这样！现在您可以列出并使用 conan-center-index 本地文件夹中的包了：
$ conan list "zlib/*" -r=mycenter
mycenter
zlib
zlib/1.2.11
zlib/1.2.12
zlib/1.2.13
zlib/1.3
zlib/1.3.1
我们也可以从这个仓库安装包，例如我们可以执行：
$ conan install --requires=zlib/1.3
...
======== Computing dependency graph ========
zlib/1.3: Not found in local cache, looking in remotes...
zlib/1.3: Checking remote: mycenter
zlib/1.3: Downloaded recipe revision 5c0f3a1a222eebb6bff34980bcd3e024
Graph root
cli
Requirements
zlib/1.3#5c0f3a1a222eebb6bff34980bcd3e024 - Downloaded (mycenter)
======== Computing necessary packages ========
Requirements
zlib/1.3#5c0f3a1a222eebb6bff34980bcd3e024:72c852c5f0ae27ca0b1741e5fd7c8b8be91a590a - Missing
ERROR: Missing binary: zlib/1.3:72c852c5f0ae27ca0b1741e5fd7c8b8be91a590a
正如我们所看到的，Conan 成功地从 mycenter 获取了 zlib/1.3 的配方，但随后失败了，因为没有二进制文件。这是预期的，仓库只包含配方，不包含二进制文件。我们可以使用 --build=missing 参数从源代码构建二进制文件：
$ conan install --requires=zlib/1.3 --build=missing
...
zlib/1.3: package(): Packaged 2 '.h' files: zconf.h, zlib.h
zlib/1.3: package(): Packaged 1 file: LICENSE
zlib/1.3: package(): Packaged 1 '.a' file: libz.a
zlib/1.3: Created package revision 0466b3475bcac5c2ce37bb5deda835c3
zlib/1.3: Package '72c852c5f0ae27ca0b1741e5fd7c8b8be91a590a' created
zlib/1.3: Full package reference: zlib/1.3#5c0f3a1a222eebb6bff34980bcd3e024:72c852c5f0ae27ca0b1741e5fd7c8b8be91a590a#0466b3475bcac5c2ce37bb5deda835c3
zlib/1.3: Package folder /home/conan/.conan2/p/b/zlib1ed9fe13537a2/p
WARN: deprecated: Usage of deprecated Conan 1.X features that will be removed in Conan 2.X:
WARN: deprecated: 'cpp_info.names' used in: zlib/1.3
======== Finalizing install (deploy, generators) ========
cli: Generating aggregated env files
cli: Generated aggregated env files: ['conanbuild.sh', 'conanrun.sh']
Install finished successfully
我们现在可以在本地缓存中看到二进制包了：
$ conan list "zlib:*"
Local Cache
zlib
zlib/1.3
revisions
5c0f3a1a222eebb6bff34980bcd3e024 (2024-04-10 11:50:34 UTC)
packages
72c852c5f0ae27ca0b1741e5fd7c8b8be91a590a
info
settings
arch: x86_64
build_type: Release
compiler: gcc
compiler.version: 9
os: Linux
options
fPIC: True
shared: False
最后，将二进制包上传到我们的 Artifactory 仓库，以便我们的组织、用户和 CI 任务可以使用它：
$ conan remote add myartifactoryrepo <artifactory_url>
$ conan upload zlib* -r=myartifactoryrepo -c
通过这种方式，包的消费者不仅可以享受到预编译的二进制文件，避免总是需要从源代码重新构建所有依赖项，而且还能更强有力地保证所有依赖项及其传递依赖项都能正确构建和工作，并且它们能够很好地协同工作等。将二进制文件创建过程与二进制文件使用过程解耦是实现更快、更可靠地使用依赖项的方法。
请记住，在生产环境中，conan upload 命令应由 CI 执行，而不是开发人员，并遵循 Conan 指南。这种方法确保包消费者享受到预编译的二进制文件以及依赖项之间的一致性。
修改 local-recipes-index 仓库文件¶
这种方法的一个优点是，我们对每个配方所做的所有更改都会自动对 Conan 客户端可用。例如，对 recipes/zlib/config.yml 文件的更改会立即被 Conan 客户端识别。如果您编辑该文件并删除所有版本，只保留最新版本，然后我们 list 配方：
$ conan list "zlib/*" -r=mycenter
mycenter
zlib
zlib/1.3.1
当某些配方发生变化时，请注意当前的 Conan home 目录已经包含该包的缓存副本，因此除非我们明确使用 --update，否则它不会更新，就像任何其他 Conan 远程仓库一样。
因此，如果我们在 recipes/zlib/all/conanfile.py 中的 zlib 配方中进行更改并重复操作：
$ conan install --requires=zlib/1.3.1 -r=mycenter --update --build=missing
我们将立即在 Conan home 目录中从新修改的配方本地构建新的二进制包。
在生产中使用 local-recipes-index 仓库¶
使用此新功能时应考虑以下几个重要点：
它专为第三方包设计，即在一个仓库中的配方创建的包其源代码位于其他地方。要打包您自己的代码，建议的标准做法是将 conanfile.py 配方与源代码放在一起，并使用标准的 conan create 流程。
local-recipes-index 仓库指向文件系统中的本地文件夹。虽然用户可以选择将该文件夹与 Git 仓库或其他版本控制机制同步，但 Conan 对此是不可知的，因为它只知道文件系统中指向仓库（当前）状态的文件夹。用户可以选择直接运行 Git 命令来切换分支/提交/标签，Conan 将自动识别这些更改。
这种方法在源代码级别运行，不生成包二进制文件。对于开发和生产环境的部署，使用远程包服务器（如 Artifactory）至关重要。需要注意的是，此功能不能替代 Conan 的远程包服务器，后者在托管日常使用的包方面发挥着至关重要的作用。
此外，请注意，服务器远程仓库可以保留更改历史记录，存储多个配方修订版。相比之下，local-recipes-index 远程仓库在任何给定时间只能表示一个单一的快照。
ConanCenter 不使用
python-requires，因为这更适用于第一方包。目前，在local-recipes-index仓库中使用python-requires是可能的（且是实验性的），但前提是python-requires也位于同一个索引仓库中。不打算或不计划支持在其他仓库或用户 Conan 缓存中包含这些python-requires。
此外，此功能不支持将服务器 URL 直接放入配方中；远程仓库必须通过 conan remote add 明确添加。将抽象包要求（例如 “zlib/1.3.1”）与其特定来源解耦对于正确解析依赖关系和利用 Conan 的图谱功能至关重要，包括版本冲突检测和解决、版本范围解析、选择使用预发布版本、platform_requires、replace_requires 等。这种分离还有助于实现现代 DevOps 实践，例如包的不变性、完全可重定位性和包推广。