包身份规范化:上游库不该住在 mcpplibs(默认命名空间),版本号不该是打包计数

[Sunrisepeak]

判据

命名空间说的是这个库是谁的,不是谁打的包。版本号说的是你拿到的是哪一版上游。

两条今天都没有被一致地执行。

证据一:同一形态,两个相反的命名空间

包	tarball 归谁	形态	namespace
godotengine.godot-cpp-m	mcpplibs/godot-cpp-m	上游之上的 module 层	上游 org
mcpplibs.imgui	mcpplibs/imgui-m	上游之上的 module 层	mcpplibs

两者形态完全相同,命名空间却相反。这条规则从来没有被定下来过,是逐 PR 决定的。

mcpplibs 尤其不该被当成组织名来用 —— 它是 mcpp 的默认命名空间:

// src/pm/dep_spec.cppm
// Bare `gtest = "1.15.2"` becomes `(mcpplibs, gtest)`.
inline constexpr std::string_view kDefaultNamespace = "mcpplibs";

11 个 mcpplibs.* 里只有 cmdline / tinyhttps / llmapi 名副其实。

证据二:版本号是打包计数,用户看不出拿到哪一版库

包	索引里的版本	实际上游版本
mcpplibs.imgui	0.0.1 … 0.0.6	ImGui 1.92.8-docking
mcpplibs.ffmpeg	0.0.3	FFmpeg 8.1.2
mcpplibs.opencv	0.0.9, 0.0.10	OpenCV 5.0.0
mcpplibs.llamacpp	0.1.0	llama.cpp b10069
mcpplibs.capi:lua	0.0.3	Lua 5.4.7

对照组:compat.imgui@1.92.8、compat.ffmpeg@8.1.2、compat.lua@5.4.7、mcpplibs.grpc@1.83.0 —— 早就是对的。

关键:两件事同批做

更正:本节原先声称 tests/examples/imgui 与 imgui-window 写的是裸名,只对齐版本会静默把它们换成 module 层。那是错的 —— 那两个成员写的是 [dependencies.compat] imgui = "1.92.8",明确限定了命名空间,换不掉。我当时只看了 grep 出来的一行,没看它属于哪个 [dependencies.*] 段。

真正成立的后果是另一条:module 层的成员用的才是裸名,而它们正是要迁走的那些。迁出 mcpplibs 之后这些裸名会响亮地解析失败,所以索引 PR 必须同时更新它们:

成员	现在	迁移后
imgui-module	[target.'cfg(linux)'.dependencies] imgui = "0.0.1"	[….dependencies.ocornut] imgui = "1.92.8"
ffmpeg-module	ffmpeg = "0.0.3"	[….dependencies.ffmpeg] ffmpeg = "8.1.2"
opencv-module	opencv = "0.0.10"	[….dependencies.opencv] opencv = "5.0.0"
llamacpp	llamacpp = "0.1.0"	[….dependencies.ggml-org] llamacpp = "b10069"
grpc-module	[….dependencies.mcpplibs] grpc = "1.83.0"	[….dependencies.grpc] grpc = "1.83.0"

同批做仍然是对的,但理由退化成朴素的一条:一次迁移比两次迁移少让用户改一遍写法。

迁移表

现在	迁到	版本
mcpplibs:imgui	ocornut:imgui	1.92.8
mcpplibs:ffmpeg	ffmpeg:ffmpeg	8.1.2
mcpplibs:opencv	opencv:opencv	5.0.0
mcpplibs:llamacpp	ggml-org:llamacpp	b10069
mcpplibs.capi:lua	lua:lua	5.4.7
mcpplibs:xpkg	openxlings:xpkg	待定
mcpplibs:templates	保留	—

grpc 已单独处理:grpc:grpc / grpc:grpc-plugin,grpcgen 因为是本生态自己写的规则而留在 mcpplibs。

兼容手段

旧描述符原地冻结,不删除:老用户继续解析到旧条目,新版本只在规范命名空间下发布。这是重命名的标准做法,不需要动引擎。

代价是消费者要写限定名(ocornut.imgui = "1.92.8"),因为裸名够不到第三方命名空间。我考虑过给 mcpp 加一条可配置的裸名搜索路径(dep_spec.cppm 的注释确实指向这个方向),结论是不加:用户既然都要声明命名空间了,限定名更短也更自证,而且索引里已有 7 个包本就如此。

逐包的独立难点(都已实测)

lua —— 唯一一个模块名跟着命名空间走。 import mcpplibs.capi.lua;,改命名空间会牵出源码级破坏。其余四个的模块名(imgui / ffmpeg / opencv.cv / llamacpp)与命名空间无关,迁移不碰它们。

llamacpp —— b10069 能用,但只能精确 pin。 我先判断它"根本装不上",实测推翻了:造本地索引写入 b10069 版本键,解析、匹配、wire 寻址(probe:tinyver@b10069)全部正常。不成立的只有版本范围 —— 见 mcpp#363。

imgui —— 还有一层分层要做。 src/core.cppm(ImGui 原生 API)与 src/app.cppm(应用框架 facade)并存,而 app 目前是无条件编译的,并且 import imgui.backend.glfw_opengl3;,于是 compat.glfw 与 compat.opengl 对所有消费者都是无条件依赖 —— 只想要原生 ImGui 的人被迫带上 GLFW 与 OpenGL。应当用 [features] + [feature-deps] 把 app 与后端 gate 起来。索引成员里零消费 imgui.app,所以这一步不打断任何现有成员;imgui-m 自己的 templates/window 与 templates/docking 用了,它们声明该 feature 即可。

执行

每个包一次到位:-m 仓库 bump 版本并打 tag/release → 索引新增规范描述符 → 更新索引测试成员 → 旧描述符加弃用说明并冻结。顺序按构建代价:imgui → ffmpeg → llamacpp → opencv,lua 因模块名问题单独处理。

[Sunrisepeak]

更正:issue 正文里「两件事必须同批」那一节的论据是错的

原文声称:

tests/examples/imgui 与 tests/examples/imgui-window 写的是裸名 imgui = "1.92.8",只对齐版本会让它们在第一级命中 module 层,静默换包。

这两个成员写的是限定名。 带着段头看:

# tests/examples/imgui
[dependencies.compat]
imgui = "1.92.8"

# tests/examples/imgui-window
[target.'cfg(linux)'.dependencies.compat]
imgui = "1.92.8"

我当时只看了 grep 出来的 imgui = "1.92.8" 那一行,没有看它属于哪个 [dependencies.*] 段,于是把限定写法误读成裸名。既然明写了 compat,就没有任何东西能把它们换掉 —— 那条"静默换包"的风险不存在。

真正成立的后果是另一条

module 层的成员用的才是裸名,而它们正是要被迁走的那些:

成员	写法	迁移后
imgui-module	[target.'cfg(linux)'.dependencies] imgui = "0.0.1"	解析不到,须改 […dependencies.ocornut]
ffmpeg-module	ffmpeg = "0.0.3"	须改 […dependencies.ffmpeg]
opencv-module	opencv = "0.0.10"	须改 […dependencies.opencv]
llamacpp	llamacpp = "0.1.0"	须改 […dependencies.ggml-org]

(grpc-module 已经是限定的:[target.'cfg(linux)'.dependencies.mcpplibs] grpc = "1.83.0",改成 .grpc 即可。)

所以索引 PR 必须同时更新这四个成员的依赖写法,否则它们会在解析阶段直接失败 —— 响亮地失败,不是静默换包。这比我原先描述的风险小得多,也好查得多。

迁移本身不变

判据(命名空间说的是这个库是谁的)与版本对齐都不依赖那条错误论据。同批做仍然是对的,但理由退化成朴素的一条:一次迁移比两次迁移少让用户改一遍写法。