使用包列表¶
注意
此功能处于预览状态。这意味着它极不可能被删除,也极不可能发生破坏性更改。维护者将尽可能避免破坏它,只在非常必要时才这样做。有关更多信息,请参阅 Conan 稳定性 部分。
包列表是 Conan 的一个强大且便捷的功能,可以自动化和串联不同的 Conan 命令。让我们看一些常见的用例。
列出包并下载它们¶
第一个简单的用例可以是列出服务器上的一些食谱和/或二进制文件,然后下载它们。
我们可以执行任何 conan list 命令,例如,列出所有版本高于 1.2.11 的 zlib 版本,最新的食谱修订版,该最新食谱修订版的所有 Windows 二进制文件,最后是每个二进制文件的最新包修订版。
注意
如果我们稍后实际要下载某个内容,则必须在 conan list 模式中指定包修订版,例如 latest,否则只会下载食谱。
$ conan list "zlib/[>1.2.11]#latest:*#latest" -p os=Windows --format=json -r=conancenter > pkglist.json
命令的输出以 json 格式发送到文件 pkglist.json,该文件如下所示:
"conancenter": {
"zlib/1.2.12": {
"revisions": {
"b1fd071d8a2234a488b3ff74a3526f81": {
"timestamp": 1667396813.987,
"packages": {
"ae9eaf478e918e6470fe64a4d8d4d9552b0b3606": {
"revisions": {
"19808a47de859c2408ffcf8e5df1fdaf": {
}
},
"info": {
"settings": {
"arch": "x86_64",
"os": "Windows"
}
}
}
}
}
},
"zlib/1.2.13": {
}
}
pkglist.json 的第一级是“origin”远程,如果是发生在缓存中的列表,则是“Local Cache”。在这种情况下,由于我们在 conancenter 远程上列出了包,因此该远程将是 origin。
现在,我们可以使用一个 conan download 调用来下载这些食谱和二进制文件。
$ conan download --list=pkglist.json -r=conancenter
# Download the recipes and binaries in pkglist.json
# And displays a report of the downloaded things
从一个远程下载并上传到另一个远程¶
假设我们从上一步下载的包创建一个新的包列表。
$ conan download --list=pkglist.json -r=conancenter --format=json > downloaded.json
# Download the recipes and binaries in pkglist.json
# And stores the result in "downloaded.json"
生成的 downloaded.json 文件将与 pkglist.json 文件几乎相同,但在此情况下,这些包的“origin”是 "Local Cache"(因为下载的包将在缓存中)。
"Local Cache": {
"zlib/1.2.12": {
"revisions": {
}
}
}
这意味着我们现在可以将同一组食谱和二进制文件上传到另一个远程。
$ conan upload --list=downloaded.json -r=myremote -c
# Upload those artifacts to the same remote
注意
最佳实践
这是一种运行不同服务器存储库之间推广的缓慢机制。像 Artifactory 这样的服务器提供了无需客户端即可直接将包从一个存储库复制到另一个存储库的方法,由于文件去重,这种方法速度要快得多,因此这是推荐的方法。本节介绍的方法可能用于隔离环境以及无法进行服务器到服务器复制的其他情况。
构建和上传包¶
最有趣的流程之一是,当某些包在本地缓存中构建时,使用 conan create 或 conan install --build=xxx 命令。通常,我们会希望将本地构建的包上传到服务器,以免它们被其他人重新构建。但我们可能只想上传已构建的二进制文件,而不是所有其他传递性依赖项,或者之前在本地缓存中的其他包。
可以从 conan install、conan create 和 conan graph info 命令的输出来计算包列表。然后,可以使用该包列表进行上传。分步操作:
首先,假设我们有自己的包 mypkg/0.1,然后我们创建它。
$ conan new cmake_lib -d name=mypkg -d version=0.1
$ conan create . --format=json > create.json
这将创建一个图的 JSON 表示,其中包含有关已构建包的信息 "binary": "Build"。
{
"graph": {
"nodes": {
"0": {
"ref": "conanfile",
"id": "0",
"recipe": "Cli",
"context": "host",
"test": false
},
"1": {
"ref": "mypkg/0.1#f57cc9a1824f47af2f52df0dbdd440f6",
"id": "1",
"recipe": "Cache",
"package_id": "2401fa1d188d289bb25c37cfa3317e13e377a351",
"prev": "75f44d989175c05bc4be2399edc63091",
"build_id": null,
"binary": "Build"
}
}
}
我们可以从该文件计算包列表,然后使用以下命令将这些工件上传到服务器:
$ conan list --graph=create.json --graph-binaries=build --format=json > pkglist.json
# Create a pkglist.json with the known list of recipes and binaries built from sources
$ conan upload --list=pkglist.json -r=myremote -c
删除包列表¶
还可以先 conan list 并创建一个要删除的列表,然后删除它们。
# Removes everything from the cache
$ conan list "*#*" --format=json > pkglist.json
$ conan remove --list=pkglist.json -c
请注意,在这种情况下,list 和 remove 的默认模式不同,因为 conan remove 具有破坏性。
当一个食谱被传递给
remove时,例如conan remove zlib/1.2.13,它将删除zlib/1.2.13的食谱及其所有二进制文件,因为二进制文件无法在没有食谱的情况下存在。当传递一个
package_id时,例如conan remove zlib/1.2.13:package_id,那么将删除指定的package_id,但不会删除食谱。
因此,如果我们直接调用 conan remove 或先调用 conan list,则删除所有内容的模式将不同,例如:
# Removes everything from the cache
$ conan remove "*"
# OR via list, we need to explicitly include all revisions
$ conan list "*#*" --format=json > pkglist.json
$ conan remove --list=pkglist.json -c
# Removes only the binaries from the cache (leave recipes)
$ conan remove "*:*"
# OR via list, we need to explicitly include all revisions
$ conan list "*#*:*" --format=json > pkglist.json
$ conan remove --list=pkglist.json -c
有关更多信息,请参阅 命令参考部分。