MongoDB 仓库 rapidyaml 多平台 Wheel 构建与 S3 简单索引发布指南【免费下载链接】mongoThe MongoDB Database项目地址: https://gitcode.com/GitHub_Trending/mo/mongo本篇技术指南围绕 MongoDB 仓库GitHub_Trending/mo/mongo中buildscripts/mongo_rapidyaml_builds/目录展开完整讲解如何为 Python 生态的rapidyaml即rymlRapid YAML 的 Python 绑定构建多平台、带版本号的 wheel 产物并通过regenerate_simple_index.py维护 S3 上符合 PEP 503 规范的简单索引供 Poetry / uv / pip 直接消费。读完本文你将掌握 Linuxmanylinux2014含 x86_64/aarch64/s390x/ppc64le 四种架构、macOSx86_64/arm64与 Windows x86_64 三类平台的 wheel 构建流程理解每个环境变量的作用以及为什么简单索引上的#sha256hex片段对poetry lock和rules_pycross的uv_translator至关重要。为什么 MongoDB 需要自己构建 rapidyaml wheel在 MongoDB 仓库的 Python 工具链位于 pyproject.toml中rapidyaml是一个构建期依赖。它通过 C 的 Rapid YAML 库为 Python 提供高性能的 YAML 解析能力。问题在于直接使用pyproject.toml里的 git 依赖会让每次构建都去拉取源码、编译 C 扩展既慢又不稳定。该目录的定位在 README.md 中写得很清楚产出带版本号的rapidyamlwheel上传到 S3供仓库直接消费从而替代从 git 依赖现场构建。围绕这个目标目录里包含四个文件文件作用build_rapidyaml_manylinux2014.shLinux 平台 wheel 构建Docker manylinux2014 镜像build_rapidyaml_macos.shmacOS 平台 wheel 构建本机原生构建build_rapidyaml_windows_x64.ps1Windows x86_64 wheel 构建Developer PowerShellregenerate_simple_index.py重新生成 S3 上 PEP 503 简单索引为每个链接附加#sha256片段固定的源码版本与必须显式指定的发布版本所有脚本默认克隆mongodb-forks/rapidyaml仓库一个 fork并检出当前固定在 pyproject.toml 中的提交a5d485fd44719e1c03e059177fc1f695fc462b66同时RAPIDYAML_VERSION必须显式设置例如0.9.0.post0。原因在 README 中有明确解释MongoDB 的 fork 不发布 git tagsetuptools-scm无法自行推断一个稳定的发布版本因此必须通过环境变量注入。三个脚本都会在缺少该变量时立即报错退出例如 Linux 脚本第 16-19 行RAPIDYAML_VERSION must be set (for example: 0.9.0.post0).。所有构建产物统一写入dist/可通过OUT_DIR覆盖。平台与脚本对应关系脚本平台输出build_rapidyaml_manylinux2014.shLinuxx86_64、aarch64、s390x、ppc64ledist/rapidyaml-*.whlbuild_rapidyaml_macos.shmacOS 宿主架构x86_64或arm64dist/rapidyaml-*.whlbuild_rapidyaml_windows_x64.ps1Windows x86_64dist/rapidyaml-*.whlLinux基于 manylinux2014 的跨架构构建Linux 构建脚本 build_rapidyaml_manylinux2014.sh 依赖Docker核心思路是在官方 manylinux2014 镜像内完成编译、wheel 打包与auditwheel repair从而保证产物对 glibc 的兼容性基线。启用跨架构构建若要交叉构建非本机 Linux 架构例如在 x86_64 主机上构建 aarch64/s390x/ppc64le需要先通过 QEMU binfmt一次性注册模拟执行器docker run --privileged --rm tonistiigi/binfmt --install all构建本机架构 wheelRAPIDYAML_VERSION0.9.0.post0 ./build_rapidyaml_manylinux2014.sh不设置ARCH时脚本默认取$(uname -m)源码第 5 行即构建宿主架构。交叉构建指定架构 wheelRAPIDYAML_VERSION0.9.0.post0 ARCHx86_64 PLATFORMlinux/amd64 ./build_rapidyaml_manylinux2014.sh RAPIDYAML_VERSION0.9.0.post0 ARCHaarch64 PLATFORMlinux/arm64 ./build_rapidyaml_manylinux2014.sh RAPIDYAML_VERSION0.9.0.post0 ARCHs390x PLATFORMlinux/s390x ./build_rapidyaml_manylinux2014.sh RAPIDYAML_VERSION0.9.0.post0 ARCHppc64le PLATFORMlinux/ppc64le ./build_rapidyaml_manylinux2014.shPLATFORM用于向docker run传递--platform参数脚本第 60-61 行。脚本内部的关键机制从源码可以还原完整构建链路脚本第 63-120 行的 Docker 内部命令架构 → 镜像与平台标签映射case语句将四种架构分别映射到quay.io/pypa/manylinux2014_x86_64/_aarch64/_s390x/_ppc64le镜像以及对应的AUDITWHEEL_PLATmanylinux2014_x86_64等第 21-48 行。CPU 兼容性标志为保证 wheel 可在目标架构的通用 CPU 上运行脚本为 x86_64 设置-marchx86-64 -mtunegeneric为 aarch64 设置-mcpugeneric第 26、32 行。这些标志会通过CFLAGS/CXXFLAGS导出第 94-97 行避免产物针对构建机 CPU 过度优化。检出与子模块在容器内git clone、检出指定 refgit -c advice.detachedHeadfalse checkout、git submodule update --init --recursive拉取全部子模块第 87-90 行。版本注入通过SETUPTOOLS_SCM_PRETEND_VERSION$RAPIDYAML_VERSION让setuptools-scm使用指定版本号第 92 行。构建与修复python -m build --wheel产出原始 wheelauditwheel show检查外部依赖再auditwheel repair --plat打上manylinux2014_*平台标签并把动态库打进 wheel第 99-107 行。冒烟测试与校验将修复后的 wheel 强制安装后执行import ryml并打印ryml.__file__第 113-117 行最后输出sha256sum供发布时记录哈希。Python 解释器路径由PYTHON_TAG决定默认cp313-cp313对应 manylinux 镜像内/opt/python/cp313-cp313这与仓库当前的 Python 版本一致需要为其他解释器构建时通过环境变量覆盖即可。macOS本机构建 delocate 排除 Python.frameworkmacOS 脚本 build_rapidyaml_macos.sh 的设计原则是只为宿主架构构建脚本会校验ARCH与HOST_ARCH一致第 47-51 行不一致直接退出。这样 wheel 的平台标签macosx_*_x86_64/macosx_*_arm64与解释器使用方式都保持简单直接——发布多个架构时只需分别在对应架构的机器上各跑一次。为什么用临时 virtualenv脚本创建一个临时 virtualenvmktemp -dpython -m venv第 55-58、96 行把全部构建工具安装进去。README 指出这保证了脚本在 Homebrew 管理的 Python 环境下也能工作——这类环境通常拒绝向系统环境直接pip install。脚本退出时通过trap清理临时目录第 56 行。部署目标与架构标志MACOSX_DEPLOYMENT_TARGET默认值按架构区分x86_64 为10.13arm64 为11.0第 34、39 行。x86_64 构建时设置-arch x86_64、ARCHFLAGS-arch x86_64、CMAKE_OSX_ARCHITECTURESx86_64第 68-72 行。arm64 构建时不显式传入arm64架构标志而是设置-DCMAKE_SYSTEM_PROCESSORaarch64。脚本注释解释了原因c4corerapidyaml 依赖的基础库较旧的TargetArchitecture.cmake在 macOS 上会拒绝显式arm64因此在 Apple Silicon 上原生构建并让上游项目逻辑把 CPU 视为 aarch64第 74-77 行。通过xcrun --sdk macosx --show-sdk-path获取SDKROOT第 61 行并统一在CFLAGS/CXXFLAGS/LDFLAGS中追加-mmacosx-version-min$MACOSX_DEPLOYMENT_TARGET第 62-63、117-119 行。构建依赖解析与 SWIG脚本会从被检出的pyproject.toml中读取build-system.requires通过内嵌 Python 用tomllib解析并把~规格归一化为逐条安装到 virtualenv第 124-154 行。构建完成后校验swig可用并导出SWIG_EXECUTABLE与SWIG_DIR第 156-166 行——rapidyaml 的 Python 绑定依赖 SWIG 生成胶水代码。delocate排除 Python.frameworkwheel 修复使用delocate-wheel并且显式排除Python.framework--exclude Python.framework第 177 行。脚本注释说明扩展应当从目标 Python 安装加载libpython而不是把解释器框架打进 wheel。README 进一步提醒这要求构建 wheel 所用的 Python 发行版家族与最终消费方的 Python 保持一致。使用方法RAPIDYAML_VERSION0.9.0.post0 PYTHON_BINpython3.13 ./build_rapidyaml_macos.shWindows x86_64MSVC 环境导入 delvewheel 修复Windows 脚本 build_rapidyaml_windows_x64.ps1 面向x86_64-pc-windows-msvc。README 建议在Developer PowerShell for Visual Studio中运行以保证cl.exe可用——不过脚本本身也实现了 MSVC 环境的自动探测与导入Import-MsvcEnvironment函数第 15-102 行按以下顺序寻找环境变量VCVARS64_BAT、VSDEVCMD_BAT显式指定的批处理通过vswhere.exeVisual Studio Installer 的标准查询工具定位安装路径遍历Program Files\Microsoft Visual Studio\{2022,2019}\{Enterprise,Professional,Community,BuildTools}下的vcvars64.bat/VsDevCmd.bat。找到后执行call ... nul set解析输出的环境变量注入当前进程第 79-93 行并验证cl.exe是否可用。若cl.exe、git.exe缺失则直接抛错第 117-122 行。其余流程与另外两个平台一致创建 virtualenv → 克隆并检出 ref、初始化子模块 →SETUPTOOLS_SCM_PRETEND_VERSION注入版本 → 安装pip26、setuptools、wheel、build、delvewheel、packaging26第 158 行→ 读取build-system.requires逐条安装 →python -m build --wheel --no-isolation构建 →delvewheel repair修复 → 强制安装后import ryml冒烟测试第 222-223 行→ 输出 SHA256。构建根目录带 GUID 后缀第 127 行finally块确保清理第 230-236 行。使用方法$env:RAPIDYAML_VERSION 0.9.0.post0 $env:PYTHON_BIN C:\Python313\python.exe .\build_rapidyaml_windows_x64.ps1注意 README 的补充说明当前 pyproject.toml 在 Windows 上排除了rapidyaml因此 Windows wheel 目前并非必需仅当该平台标记将来改变时才需要发布。环境变量总览变量用途默认值RAPIDYAML_REPO要克隆的 git 仓库https://github.com/mongodb-forks/rapidyaml.gitRAPIDYAML_REF要构建的分支 / 标签 / 提交a5d485fd44719e1c03e059177fc1f695fc462b66RAPIDYAML_VERSION传给setuptools-scm的显式 wheel 版本必需无默认值OUT_DIR输出目录./distPYTHON_TAGmanylinux Python 解释器标签cp313-cp313PYTHON_BINmacOS / Windows 的宿主 Python 可执行文件macOS 为python3Windows 为pythonARCH目标架构宿主架构PLATFORMLinux 的 Docker 平台覆盖自动CPU_FLAGS额外的 C/C CPU 可移植性标志平台相关默认值MACOSX_DEPLOYMENT_TARGETmacOS 最低系统版本x86_64 为10.13arm64 为11.0此外Linux 脚本还支持CMAKE_BUILD_PARALLEL_LEVEL默认取nproc控制并行编译macOS 脚本支持CMAKE_FLAGS向 CMake 追加参数macOS 脚本第 66 行。消费 Wheel用 URL 平台标记替换 git 依赖wheel 上传到 S3 后可以把 pyproject.toml 中当前的 git 依赖替换为基于 URL、按平台标记区分的条目。README 给出的示例rapidyaml { url https://your-bucket/rapidyaml/0.9.0.post0/rapidyaml-0.9.0.post0-cp313-cp313-manylinux2014_x86_64.whl, markers platform_system Linux and platform_machine x86_64 }每个架构 / 平台各配置一条带markers的 URL 依赖pip / Poetry / uv 会依据运行平台自动选择正确的 wheel。维护 PEP 503 简单索引regenerate_simple_index.py构建好的 wheel 最终存放在 S3 桶mdb-build-public的rapidyaml_wheels/前缀下仓库通过一个PEP 503 简单索引来消费它们。该索引声明在 pyproject.toml 中该文件同时保留了 Poetry 风格的[[tool.poetry.source]]与 uv 风格的[[tool.uv.index]]两套声明语义等价[[tool.poetry.source]] name mdb-build-public url https://mdb-build-public.s3.amazonaws.com/rapidyaml_wheels/simple/ priority explicit [[tool.uv.index]] name mdb-build-public url https://mdb-build-public.s3.amazonaws.com/rapidyaml_wheels/simple/ explicit true [tool.uv.sources] rapidyaml { index mdb-build-public }explicit truePoetry 的priority explicit意味着 uv / Poetry 只为通过[tool.uv.sources]或等价机制显式指定的包即rapidyaml查询该索引其余依赖仍从默认源解析。为什么索引必须携带#sha256hex片段PEP 503 允许索引中每个a锚点携带#sha256hexURL 片段。Poetry 及其他遵循 PEP 503 的安装器会用它校验下载并直接填充 lockfile 中的哈希而无需本地重新哈希。历史索引只发布裸 URL无片段导致每次涉及rapidyaml的poetry lock都要重新下载每个 wheel 来计算哈希。带上片段后poetry lock以及未来的uv lock可以直接从索引取哈希不再重复下载未来要求索引必须携带哈希的安装器——例如rules_pycross的uv_translator缺少片段时会在哈希缺失的 lock 条目上以KeyError: hash失败——可以直接对该桶工作无需额外管道。这一点也在 pyproject.toml 第 104-109 行的注释中得到印证仓库用uv sync --no-group powercycle-incompatible在特定远程环境排除该依赖组并在发布新 wheel 后通过regenerate_simple_index.py重新生成索引以便 uv 将#sha256hex哈希持久化进uv.lockrules_pycross需要它们。同时rapidyaml0.9.0.post0被置于powercycle-incompatible组第 110-112 行说明该依赖在某些 powercycle 远程发行版上存在兼容性问题这也是构建固定版本 wheel 的重要原因之一。使用方式# 可选预览将两个索引页面写到 stdout不上传 python3 buildscripts/mongo_rapidyaml_builds/regenerate_simple_index.py --dry-run # 正式执行 —— 就地重写索引 python3 buildscripts/mongo_rapidyaml_builds/regenerate_simple_index.py前提条件需要具备对mdb-build-public桶的s3:List/Get/Put权限的 AWS 凭证脚本依赖boto3缺失时提示通过poetry install --with aws或pip install boto3安装见脚本第 65-72 行。该脚本还通过 BUILD.bazel 暴露为py_binary目标regenerate_simple_index依赖boto3便于 Bazel 环境引用。脚本内部机制从 regenerate_simple_index.py 源码可以还原其完整行为列出产物分页ListObjectsV2枚举rapidyaml_wheels/前缀下的对象跳过目录标记对象、simple/嵌套内容只保留.whl与.tar.gz第 95-111 行。本地计算 sha256对每个产物流式下载并本地计算整对象 sha2561 MiB 分块第 114-124 行。脚本 docstring 明确解释了原因S3 的ETag对 multipart 上传的对象是md5(md5(part1)md5(part2)...)-n形式既不是整对象 sha256 也不是整对象 md5因此不可信。下载开销很小每个 wheel 约几 MB 到几十 MB。渲染索引用xml.etree.ElementTree构造最小 HTML5 页面保证属性正确转义每个a的 href 形如https://mdb-build-public.s3.amazonaws.com/rapidyaml_wheels/filename#sha256hex锚点文本为文件名第 127-163 行。写入四个 S3 key两对字节相同的副本Key作用rapidyaml_wheels/simple/rapidyaml/尾斜杠 key。安装器按 PEP 503 精确请求.../simple/rapidyaml/而s3.amazonaws.com按字面提供 key、不会像静态网站端点那样把/重写到/index.html所以必须存在这个精确 keyrapidyaml_wheels/simple/rapidyaml/index.html供人类点击浏览并为将来可能的 S3 静态网站托管预留rapidyaml_wheels/simple/尾斜杠根索引列出项目名当前只有rapidyamlrapidyaml_wheels/simple/index.html与上面内容相同的镜像两份项目索引页面上的每个锚点都带#sha256hex片段。这种尾斜杠 key index.html 镜像双写模式是普通 S3 端点不做/→/index.html重写与静态网站端点行为差异下的兼容方案。三平台构建行为的共同点与差异环节Linux (manylinux2014)macOSWindows构建环境Docker 容器manylinux2014 镜像临时 virtualenv 宿主 Pythonvirtualenv MSVC源码获取容器内git clone 检出 ref 子模块本机git clone 检出 ref 子模块本机git clone 检出 ref 子模块版本注入SETUPTOOLS_SCM_PRETEND_VERSION同左同左wheel 修复auditwheel repairdelocate-wheel排除Python.frameworkdelvewheel repair冒烟测试import ryml 打印ryml.__file__同左同左校验输出sha256sumshasum -a 256Get-FileHash -Algorithm SHA256三个脚本都遵循同一套可复现流程克隆mongodb-forks/rapidyaml→ 检出固定 ref → 初始化子模块 → 注入显式版本构建 wheel → 平台化修复 →import ryml冒烟测试 → 计算并打印 SHA256。总结完整发布流程将上述内容串成一条可操作的发布流水线构建在目标平台上运行对应脚本Linux 通过 Docker 可选 QEMU 交叉构建四种架构macOS 在每种目标架构的本机各跑一次Windows 在 Developer PowerShell 中运行始终设置RAPIDYAML_VERSION。检查产物确认dist/下生成的rapidyaml-*.whl平台标签正确、冒烟测试通过、SHA256 已记录。上传将 wheel及可选 sdist上传到s3://mdb-build-public/rapidyaml_wheels/。重建索引运行regenerate_simple_index.py建议先--dry-run预览为四个 S3 key 写入带#sha256片段的 PEP 503 索引。消费更新 pyproject.toml 中的依赖声明URL 平台标记或通过[[tool.uv.index]][tool.uv.sources]指向简单索引执行poetry lock/uv lock时即可直接从索引获取哈希无需重复下载校验rules_pycross的哈希验证要求也随之满足。【免费下载链接】mongoThe MongoDB Database项目地址: https://gitcode.com/GitHub_Trending/mo/mongo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/11 13:39:36 · 阅读 1.2k MongoDB 仓库 rapidyaml 多平台 Wheel 构建与 S3 简单索引发布指南
MongoDB 仓库 rapidyaml 多平台 Wheel 构建与 S3 简单索引发布指南【免费下载链接】mongoThe MongoDB Database项目地址: https://gitcode.com/GitHub_Trending/mo/mongo本篇技术指南围绕 MongoDB 仓库GitHub_Trending/mo/mongo中buildscripts/mongo_rapidyaml_builds/目录展开完整讲解如何为 Python 生态的rapidyaml即rymlRapid YAML 的 Python 绑定构建多平台、带版本号的 wheel 产物并通过regenerate_simple_index.py维护 S3 上符合 PEP 503 规范的简单索引供 Poetry / uv / pip 直接消费。读完本文你将掌握 Linuxmanylinux2014含 x86_64/aarch64/s390x/ppc64le 四种架构、macOSx86_64/arm64与 Windows x86_64 三类平台的 wheel 构建流程理解每个环境变量的作用以及为什么简单索引上的#sha256hex片段对poetry lock和rules_pycross的uv_translator至关重要。为什么 MongoDB 需要自己构建 rapidyaml wheel在 MongoDB 仓库的 Python 工具链位于 pyproject.toml中rapidyaml是一个构建期依赖。它通过 C 的 Rapid YAML 库为 Python 提供高性能的 YAML 解析能力。问题在于直接使用pyproject.toml里的 git 依赖会让每次构建都去拉取源码、编译 C 扩展既慢又不稳定。该目录的定位在 README.md 中写得很清楚产出带版本号的rapidyamlwheel上传到 S3供仓库直接消费从而替代从 git 依赖现场构建。围绕这个目标目录里包含四个文件文件作用build_rapidyaml_manylinux2014.shLinux 平台 wheel 构建Docker manylinux2014 镜像build_rapidyaml_macos.shmacOS 平台 wheel 构建本机原生构建build_rapidyaml_windows_x64.ps1Windows x86_64 wheel 构建Developer PowerShellregenerate_simple_index.py重新生成 S3 上 PEP 503 简单索引为每个链接附加#sha256片段固定的源码版本与必须显式指定的发布版本所有脚本默认克隆mongodb-forks/rapidyaml仓库一个 fork并检出当前固定在 pyproject.toml 中的提交a5d485fd44719e1c03e059177fc1f695fc462b66同时RAPIDYAML_VERSION必须显式设置例如0.9.0.post0。原因在 README 中有明确解释MongoDB 的 fork 不发布 git tagsetuptools-scm无法自行推断一个稳定的发布版本因此必须通过环境变量注入。三个脚本都会在缺少该变量时立即报错退出例如 Linux 脚本第 16-19 行RAPIDYAML_VERSION must be set (for example: 0.9.0.post0).。所有构建产物统一写入dist/可通过OUT_DIR覆盖。平台与脚本对应关系脚本平台输出build_rapidyaml_manylinux2014.shLinuxx86_64、aarch64、s390x、ppc64ledist/rapidyaml-*.whlbuild_rapidyaml_macos.shmacOS 宿主架构x86_64或arm64dist/rapidyaml-*.whlbuild_rapidyaml_windows_x64.ps1Windows x86_64dist/rapidyaml-*.whlLinux基于 manylinux2014 的跨架构构建Linux 构建脚本 build_rapidyaml_manylinux2014.sh 依赖Docker核心思路是在官方 manylinux2014 镜像内完成编译、wheel 打包与auditwheel repair从而保证产物对 glibc 的兼容性基线。启用跨架构构建若要交叉构建非本机 Linux 架构例如在 x86_64 主机上构建 aarch64/s390x/ppc64le需要先通过 QEMU binfmt一次性注册模拟执行器docker run --privileged --rm tonistiigi/binfmt --install all构建本机架构 wheelRAPIDYAML_VERSION0.9.0.post0 ./build_rapidyaml_manylinux2014.sh不设置ARCH时脚本默认取$(uname -m)源码第 5 行即构建宿主架构。交叉构建指定架构 wheelRAPIDYAML_VERSION0.9.0.post0 ARCHx86_64 PLATFORMlinux/amd64 ./build_rapidyaml_manylinux2014.sh RAPIDYAML_VERSION0.9.0.post0 ARCHaarch64 PLATFORMlinux/arm64 ./build_rapidyaml_manylinux2014.sh RAPIDYAML_VERSION0.9.0.post0 ARCHs390x PLATFORMlinux/s390x ./build_rapidyaml_manylinux2014.sh RAPIDYAML_VERSION0.9.0.post0 ARCHppc64le PLATFORMlinux/ppc64le ./build_rapidyaml_manylinux2014.shPLATFORM用于向docker run传递--platform参数脚本第 60-61 行。脚本内部的关键机制从源码可以还原完整构建链路脚本第 63-120 行的 Docker 内部命令架构 → 镜像与平台标签映射case语句将四种架构分别映射到quay.io/pypa/manylinux2014_x86_64/_aarch64/_s390x/_ppc64le镜像以及对应的AUDITWHEEL_PLATmanylinux2014_x86_64等第 21-48 行。CPU 兼容性标志为保证 wheel 可在目标架构的通用 CPU 上运行脚本为 x86_64 设置-marchx86-64 -mtunegeneric为 aarch64 设置-mcpugeneric第 26、32 行。这些标志会通过CFLAGS/CXXFLAGS导出第 94-97 行避免产物针对构建机 CPU 过度优化。检出与子模块在容器内git clone、检出指定 refgit -c advice.detachedHeadfalse checkout、git submodule update --init --recursive拉取全部子模块第 87-90 行。版本注入通过SETUPTOOLS_SCM_PRETEND_VERSION$RAPIDYAML_VERSION让setuptools-scm使用指定版本号第 92 行。构建与修复python -m build --wheel产出原始 wheelauditwheel show检查外部依赖再auditwheel repair --plat打上manylinux2014_*平台标签并把动态库打进 wheel第 99-107 行。冒烟测试与校验将修复后的 wheel 强制安装后执行import ryml并打印ryml.__file__第 113-117 行最后输出sha256sum供发布时记录哈希。Python 解释器路径由PYTHON_TAG决定默认cp313-cp313对应 manylinux 镜像内/opt/python/cp313-cp313这与仓库当前的 Python 版本一致需要为其他解释器构建时通过环境变量覆盖即可。macOS本机构建 delocate 排除 Python.frameworkmacOS 脚本 build_rapidyaml_macos.sh 的设计原则是只为宿主架构构建脚本会校验ARCH与HOST_ARCH一致第 47-51 行不一致直接退出。这样 wheel 的平台标签macosx_*_x86_64/macosx_*_arm64与解释器使用方式都保持简单直接——发布多个架构时只需分别在对应架构的机器上各跑一次。为什么用临时 virtualenv脚本创建一个临时 virtualenvmktemp -dpython -m venv第 55-58、96 行把全部构建工具安装进去。README 指出这保证了脚本在 Homebrew 管理的 Python 环境下也能工作——这类环境通常拒绝向系统环境直接pip install。脚本退出时通过trap清理临时目录第 56 行。部署目标与架构标志MACOSX_DEPLOYMENT_TARGET默认值按架构区分x86_64 为10.13arm64 为11.0第 34、39 行。x86_64 构建时设置-arch x86_64、ARCHFLAGS-arch x86_64、CMAKE_OSX_ARCHITECTURESx86_64第 68-72 行。arm64 构建时不显式传入arm64架构标志而是设置-DCMAKE_SYSTEM_PROCESSORaarch64。脚本注释解释了原因c4corerapidyaml 依赖的基础库较旧的TargetArchitecture.cmake在 macOS 上会拒绝显式arm64因此在 Apple Silicon 上原生构建并让上游项目逻辑把 CPU 视为 aarch64第 74-77 行。通过xcrun --sdk macosx --show-sdk-path获取SDKROOT第 61 行并统一在CFLAGS/CXXFLAGS/LDFLAGS中追加-mmacosx-version-min$MACOSX_DEPLOYMENT_TARGET第 62-63、117-119 行。构建依赖解析与 SWIG脚本会从被检出的pyproject.toml中读取build-system.requires通过内嵌 Python 用tomllib解析并把~规格归一化为逐条安装到 virtualenv第 124-154 行。构建完成后校验swig可用并导出SWIG_EXECUTABLE与SWIG_DIR第 156-166 行——rapidyaml 的 Python 绑定依赖 SWIG 生成胶水代码。delocate排除 Python.frameworkwheel 修复使用delocate-wheel并且显式排除Python.framework--exclude Python.framework第 177 行。脚本注释说明扩展应当从目标 Python 安装加载libpython而不是把解释器框架打进 wheel。README 进一步提醒这要求构建 wheel 所用的 Python 发行版家族与最终消费方的 Python 保持一致。使用方法RAPIDYAML_VERSION0.9.0.post0 PYTHON_BINpython3.13 ./build_rapidyaml_macos.shWindows x86_64MSVC 环境导入 delvewheel 修复Windows 脚本 build_rapidyaml_windows_x64.ps1 面向x86_64-pc-windows-msvc。README 建议在Developer PowerShell for Visual Studio中运行以保证cl.exe可用——不过脚本本身也实现了 MSVC 环境的自动探测与导入Import-MsvcEnvironment函数第 15-102 行按以下顺序寻找环境变量VCVARS64_BAT、VSDEVCMD_BAT显式指定的批处理通过vswhere.exeVisual Studio Installer 的标准查询工具定位安装路径遍历Program Files\Microsoft Visual Studio\{2022,2019}\{Enterprise,Professional,Community,BuildTools}下的vcvars64.bat/VsDevCmd.bat。找到后执行call ... nul set解析输出的环境变量注入当前进程第 79-93 行并验证cl.exe是否可用。若cl.exe、git.exe缺失则直接抛错第 117-122 行。其余流程与另外两个平台一致创建 virtualenv → 克隆并检出 ref、初始化子模块 →SETUPTOOLS_SCM_PRETEND_VERSION注入版本 → 安装pip26、setuptools、wheel、build、delvewheel、packaging26第 158 行→ 读取build-system.requires逐条安装 →python -m build --wheel --no-isolation构建 →delvewheel repair修复 → 强制安装后import ryml冒烟测试第 222-223 行→ 输出 SHA256。构建根目录带 GUID 后缀第 127 行finally块确保清理第 230-236 行。使用方法$env:RAPIDYAML_VERSION 0.9.0.post0 $env:PYTHON_BIN C:\Python313\python.exe .\build_rapidyaml_windows_x64.ps1注意 README 的补充说明当前 pyproject.toml 在 Windows 上排除了rapidyaml因此 Windows wheel 目前并非必需仅当该平台标记将来改变时才需要发布。环境变量总览变量用途默认值RAPIDYAML_REPO要克隆的 git 仓库https://github.com/mongodb-forks/rapidyaml.gitRAPIDYAML_REF要构建的分支 / 标签 / 提交a5d485fd44719e1c03e059177fc1f695fc462b66RAPIDYAML_VERSION传给setuptools-scm的显式 wheel 版本必需无默认值OUT_DIR输出目录./distPYTHON_TAGmanylinux Python 解释器标签cp313-cp313PYTHON_BINmacOS / Windows 的宿主 Python 可执行文件macOS 为python3Windows 为pythonARCH目标架构宿主架构PLATFORMLinux 的 Docker 平台覆盖自动CPU_FLAGS额外的 C/C CPU 可移植性标志平台相关默认值MACOSX_DEPLOYMENT_TARGETmacOS 最低系统版本x86_64 为10.13arm64 为11.0此外Linux 脚本还支持CMAKE_BUILD_PARALLEL_LEVEL默认取nproc控制并行编译macOS 脚本支持CMAKE_FLAGS向 CMake 追加参数macOS 脚本第 66 行。消费 Wheel用 URL 平台标记替换 git 依赖wheel 上传到 S3 后可以把 pyproject.toml 中当前的 git 依赖替换为基于 URL、按平台标记区分的条目。README 给出的示例rapidyaml { url https://your-bucket/rapidyaml/0.9.0.post0/rapidyaml-0.9.0.post0-cp313-cp313-manylinux2014_x86_64.whl, markers platform_system Linux and platform_machine x86_64 }每个架构 / 平台各配置一条带markers的 URL 依赖pip / Poetry / uv 会依据运行平台自动选择正确的 wheel。维护 PEP 503 简单索引regenerate_simple_index.py构建好的 wheel 最终存放在 S3 桶mdb-build-public的rapidyaml_wheels/前缀下仓库通过一个PEP 503 简单索引来消费它们。该索引声明在 pyproject.toml 中该文件同时保留了 Poetry 风格的[[tool.poetry.source]]与 uv 风格的[[tool.uv.index]]两套声明语义等价[[tool.poetry.source]] name mdb-build-public url https://mdb-build-public.s3.amazonaws.com/rapidyaml_wheels/simple/ priority explicit [[tool.uv.index]] name mdb-build-public url https://mdb-build-public.s3.amazonaws.com/rapidyaml_wheels/simple/ explicit true [tool.uv.sources] rapidyaml { index mdb-build-public }explicit truePoetry 的priority explicit意味着 uv / Poetry 只为通过[tool.uv.sources]或等价机制显式指定的包即rapidyaml查询该索引其余依赖仍从默认源解析。为什么索引必须携带#sha256hex片段PEP 503 允许索引中每个a锚点携带#sha256hexURL 片段。Poetry 及其他遵循 PEP 503 的安装器会用它校验下载并直接填充 lockfile 中的哈希而无需本地重新哈希。历史索引只发布裸 URL无片段导致每次涉及rapidyaml的poetry lock都要重新下载每个 wheel 来计算哈希。带上片段后poetry lock以及未来的uv lock可以直接从索引取哈希不再重复下载未来要求索引必须携带哈希的安装器——例如rules_pycross的uv_translator缺少片段时会在哈希缺失的 lock 条目上以KeyError: hash失败——可以直接对该桶工作无需额外管道。这一点也在 pyproject.toml 第 104-109 行的注释中得到印证仓库用uv sync --no-group powercycle-incompatible在特定远程环境排除该依赖组并在发布新 wheel 后通过regenerate_simple_index.py重新生成索引以便 uv 将#sha256hex哈希持久化进uv.lockrules_pycross需要它们。同时rapidyaml0.9.0.post0被置于powercycle-incompatible组第 110-112 行说明该依赖在某些 powercycle 远程发行版上存在兼容性问题这也是构建固定版本 wheel 的重要原因之一。使用方式# 可选预览将两个索引页面写到 stdout不上传 python3 buildscripts/mongo_rapidyaml_builds/regenerate_simple_index.py --dry-run # 正式执行 —— 就地重写索引 python3 buildscripts/mongo_rapidyaml_builds/regenerate_simple_index.py前提条件需要具备对mdb-build-public桶的s3:List/Get/Put权限的 AWS 凭证脚本依赖boto3缺失时提示通过poetry install --with aws或pip install boto3安装见脚本第 65-72 行。该脚本还通过 BUILD.bazel 暴露为py_binary目标regenerate_simple_index依赖boto3便于 Bazel 环境引用。脚本内部机制从 regenerate_simple_index.py 源码可以还原其完整行为列出产物分页ListObjectsV2枚举rapidyaml_wheels/前缀下的对象跳过目录标记对象、simple/嵌套内容只保留.whl与.tar.gz第 95-111 行。本地计算 sha256对每个产物流式下载并本地计算整对象 sha2561 MiB 分块第 114-124 行。脚本 docstring 明确解释了原因S3 的ETag对 multipart 上传的对象是md5(md5(part1)md5(part2)...)-n形式既不是整对象 sha256 也不是整对象 md5因此不可信。下载开销很小每个 wheel 约几 MB 到几十 MB。渲染索引用xml.etree.ElementTree构造最小 HTML5 页面保证属性正确转义每个a的 href 形如https://mdb-build-public.s3.amazonaws.com/rapidyaml_wheels/filename#sha256hex锚点文本为文件名第 127-163 行。写入四个 S3 key两对字节相同的副本Key作用rapidyaml_wheels/simple/rapidyaml/尾斜杠 key。安装器按 PEP 503 精确请求.../simple/rapidyaml/而s3.amazonaws.com按字面提供 key、不会像静态网站端点那样把/重写到/index.html所以必须存在这个精确 keyrapidyaml_wheels/simple/rapidyaml/index.html供人类点击浏览并为将来可能的 S3 静态网站托管预留rapidyaml_wheels/simple/尾斜杠根索引列出项目名当前只有rapidyamlrapidyaml_wheels/simple/index.html与上面内容相同的镜像两份项目索引页面上的每个锚点都带#sha256hex片段。这种尾斜杠 key index.html 镜像双写模式是普通 S3 端点不做/→/index.html重写与静态网站端点行为差异下的兼容方案。三平台构建行为的共同点与差异环节Linux (manylinux2014)macOSWindows构建环境Docker 容器manylinux2014 镜像临时 virtualenv 宿主 Pythonvirtualenv MSVC源码获取容器内git clone 检出 ref 子模块本机git clone 检出 ref 子模块本机git clone 检出 ref 子模块版本注入SETUPTOOLS_SCM_PRETEND_VERSION同左同左wheel 修复auditwheel repairdelocate-wheel排除Python.frameworkdelvewheel repair冒烟测试import ryml 打印ryml.__file__同左同左校验输出sha256sumshasum -a 256Get-FileHash -Algorithm SHA256三个脚本都遵循同一套可复现流程克隆mongodb-forks/rapidyaml→ 检出固定 ref → 初始化子模块 → 注入显式版本构建 wheel → 平台化修复 →import ryml冒烟测试 → 计算并打印 SHA256。总结完整发布流程将上述内容串成一条可操作的发布流水线构建在目标平台上运行对应脚本Linux 通过 Docker 可选 QEMU 交叉构建四种架构macOS 在每种目标架构的本机各跑一次Windows 在 Developer PowerShell 中运行始终设置RAPIDYAML_VERSION。检查产物确认dist/下生成的rapidyaml-*.whl平台标签正确、冒烟测试通过、SHA256 已记录。上传将 wheel及可选 sdist上传到s3://mdb-build-public/rapidyaml_wheels/。重建索引运行regenerate_simple_index.py建议先--dry-run预览为四个 S3 key 写入带#sha256片段的 PEP 503 索引。消费更新 pyproject.toml 中的依赖声明URL 平台标记或通过[[tool.uv.index]][tool.uv.sources]指向简单索引执行poetry lock/uv lock时即可直接从索引获取哈希无需重复下载校验rules_pycross的哈希验证要求也随之满足。【免费下载链接】mongoThe MongoDB Database项目地址: https://gitcode.com/GitHub_Trending/mo/mongo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考