合法conan包引用格式为package_name/version@user/channel,其中package_name仅含小写字母、数字、下划线、短横线且不以数字或短横线开头,version推荐语义化版本(如1.2.11),user和channel须显式指定且区分大小写。

conan包名和版本号怎么组合才合法
Conan 的包引用(reference)必须满足 package_name/version@user/channel 格式,其中 package_name 和 version 是必填项,user 和 channel 可选但强烈建议显式指定。不合法的命名会导致 conan create 失败或远程上传被拒。
-
package_name只能含小写字母、数字、下划线、短横线(a-z0-9_-),不能以数字或短横线开头;例如zlib合法,1zlib或-zlib非法 -
version推荐遵循语义化版本(MAJOR.MINOR.PATCH),如1.2.11;Conan 本身不限制格式,但conan-center官方仓库强制要求语义化版本,且禁止使用构建元数据(如1.2.11+build.1) -
user通常代表组织或团队名(如myorg、bincrafters),避免用user这类占位符上线;本地开发可临时用local,但 CI 中应替换为真实标识 -
channel建议固定为stable、testing、snapshot等语义明确值,不要混用大小写(STABLE和stable被视为不同 channel)
为什么 package_id 会因命名改动而变
Conan 的 package_id 不直接由包名/版本决定,而是由 settings(如 os、compiler)、options(如 shared=True)以及 requires 的依赖关系共同计算得出。但如果你在 conanfile.py 中硬编码了包名或版本(比如用于生成头文件宏),这些字符串一旦变化,就会触发源码重建,间接导致新 package_id —— 因为 conan create 默认把 exports_sources 内容纳入源码哈希。
- 避免在
conanfile.py中写死self.name = "mylib-2.0"这类带版本的名称;应只写self.name = "mylib",版本走self.version = "2.0" - 如果要用版本号生成 C++ 宏(如
MYLIB_VERSION),建议通过generate()阶段写入临时头文件,而非在package()中复制含版本字面量的源文件 - 修改
user/channel不影响package_id,但会影响远程定位——同一个package_id在不同@user/channel下是独立缓存条目
conan-center 对命名的硬性限制有哪些
向 conan-center 提交包时,命名不是“能跑就行”,而是有明确准入规则。违反任一条件都会被 CI 拒绝,常见失败点包括:
-
package_name必须与上游项目官方名称一致(如 OpenSSL →openssl,不是open_ssl或libopenssl) -
version必须精确匹配上游发布 tag(如 GitHub release 页面的v1.1.1w→1.1.1w,去掉v前缀;不能写成1.1.1或1.1.1w-final) -
user必须为conancenter(旧版允许conan,已弃用) -
channel必须为stable(testing仅限内部预发布流程) - 整个 reference 不能含大写字母(
OpenSSL/1.1.1w@conancenter/stable❌,正确是openssl/1.1.1w@conancenter/stable)
私有仓库要不要照搬 conan-center 规则
可以不照搬,但建议收敛命名策略,否则团队协作成本会上升。私有场景下最常被忽略的是 user 和 channel 的语义一致性:
- 多个团队共用一个远程时,
user应按组织结构划分(如infra、iot、mobile),而不是每人用自己名字 -
channel应绑定 CI 流水线阶段:比如 Jenkins job 名为deploy-to-staging,就统一用staging;避免混用dev/devel/development - 若用 Git 分支驱动构建(如
main→stable,develop→testing),需在 CI 脚本中自动提取分支名并映射,不要人工输错 - 特别注意:Conan 2.x 不再支持
@user/channel为空的 reference(即pkg/1.0),必须显式写出,哪怕只是pkg/1.0@_/_
user/channel 当作临时标记随意写,结果导致同一份二进制被反复上传多次,缓存膨胀且难以清理。命名规则本质不是语法约束,而是团队对“这个包从哪来、到哪去、谁负责”的共识表达。











