在 macOS 上使用 ApplecontainerCLI 运行 RustPython 测试完整实战指南【免费下载链接】RustPythonA Python Interpreter written in Rust项目地址: https://gitcode.com/GitHub_Trending/ru/RustPython本指南围绕 RustPython 仓库中.agents/skills/apple-container/SKILL.md这一技能文档展开讲解如何在 macOS 上使用 Apple 官方containerCLI而非 Docker / Podman启动 Linux 容器、挂载工作区、执行 RustPython 的-m test测试套件并正确解读与汇报测试结果。读完本文你将掌握一套可复用的容器化测试工作流能够在 macOS 与 Linux 之间对比测试结果、定位平台相关差异同时避免测试容器的误停误删。背景为什么用 ApplecontainerCLI 跑 RustPython 测试RustPython 是用 Rust 实现的 Python 解释器其代码库同时维护着从 CPython 移植来的 Lib/ 标准库以及位于 crates/vm 的 Rust 虚拟机实现。开发者在 macOS 上日常开发时很多行为如文件 I/O、信号处理、编码细节与 Linux 存在差异需要借助 Linux 环境做交叉验证。在 macOS 上运行 Linux 容器通常的直觉选择是 Docker 或 Podman但本技能文档明确约定NEVER use Docker, Podman, or any other container runtime. Only use thecontainercommand.严禁使用 Docker、Podman 或任何其他容器运行时只能使用container命令。这是 Apple 官方随 Xcode 提供的容器 CLI/usr/bin/container基于 macOS 自带的 Virtualization.framework 实现轻量级 Linux 虚拟机与容器管理无需额外安装 Docker 守护进程也不依赖 Docker Desktop 的许可模式。该技能的定位场景非常聚焦当用户要求在 macOS 上运行或对比 Linux 测试结果时Agent 用它把 RustPython 测试套件搬进 Linux 容器执行从而区分“RustPython 自身缺陷”与“macOS 平台差异”。前置条件与参数约定参数要执行的测试命令SKILL.md 将“Test command to run”要运行的测试命令作为唯一参数并给出三个示例test_iotest_codecs -vtest_io -v -m test_errors这些参数正是 RustPython 的 regrtest 测试框架python -m test的入参。其含义如下test_io只运行test_io这一个测试模块等价于cargo run --release -- -m test test_io-vverbose 模式逐条打印每个测试用例的执行结果-m test_errors-m/--match选项用 glob 模式过滤测试方法与用例这里表示只匹配名为test_errors的用例。参数解析逻辑可以在 Lib/test/libregrtest/cmdline.py 中找到-v/--verbose被注册为actioncount可叠加-m/--match通过自定义的FilterAction把模式累积进match_tests列表-u/--use用于启用特殊资源如-uall,-gui-j/--multiprocess控制并行进程数。前置条件运行本工作流前需确认两个前提否则命令会直接失败containerCLI 已安装通过 Homebrew 安装命令为brew install containerApple 官方容器工具随新版本 Xcode 附带Homebrew 也提供独立安装方式开发镜像rustpython-dev已构建这是预先打好的镜像内部应包含 Rust 工具链与 RustPython 的构建产物SKILL.md 假设它已存在构建细节不在本文范围。工作流详解第一步检查测试容器是否已在运行container list 2/dev/null | grep rustpython-testcontainer list列出当前所有容器2/dev/null屏蔽可能出现的噪声输出如权限提示再用grep rustpython-test过滤出本次工作流约定使用的容器名rustpython-test。如果容器已在运行直接跳到第三步执行测试即可避免重复创建同名容器导致冲突。第二步启动容器若未运行container run -d --name rustpython-test -m 8G -c 4 \ --mount typebind,source$(pwd),target/workspace \ -w /workspace rustpython-dev sleep infinity逐项拆解这条命令参数含义-ddetached 模式后台运行容器终端不被占用--name rustpython-test固定容器名供后续exec/list/rm引用-m 8G内存上限 8 GiB测试套件尤其test_io、test_codecs这类大模块对内存有一定需求-c 4分配 4 个 CPU 核心与-j并行测试可配合使用--mount typebind,source$(pwd),target/workspacebind mount 关键点把当前工作目录即 RustPython 仓库根目录挂载到容器内的/workspace-w /workspace设置容器内工作目录为/workspacerustpython-dev使用的镜像名sleep infinity容器主进程让容器保持存活等待后续exec命令bind mount 是本工作流最重要的设计SKILL.md 在 Notes 中明确说明 “The workspace is bind-mounted, so local code changes are immediately available in the container”工作区是 bind 挂载的本地代码改动会立即在容器中生效。这意味着你在宿主机修改的 Rust 源码或Lib/下的 Python 标准库文件容器内立刻可见无需重新拷贝镜像只有 Rust 代码改动需要重新编译见下方“代码变更后重建”小节。第三步在容器内执行测试命令container exec rustpython-test cargo run --release -- -m test test-argstest-args即参数部分定义的测试命令例如# 运行整个 test_io 模块 container exec rustpython-test cargo run --release -- -m test test_io # 以 verbose 模式运行 test_codecs container exec rustpython-test cargo run --release -- -m test test_codecs -v # 只运行 test_io 中的 test_errors 用例 container exec rustpython-test cargo run --release -- -m test test_io -v -m test_errors这条命令背后的调用链值得展开cargo run --release编译并运行 RustPython 的主程序入口见 src/main.rs它通过InterpreterBuilder::new()构建解释器并调用rustpython::run(config)-m test让解释器以模块方式加载 Lib/test/main.py后者调用test.libregrtest.main.main(_add_python_optsTrue)进入 regrtest 测试框架main()的入口实现在 Lib/test/libregrtest/main.pyRegrtest类“Execute a test suite”它会解析命令行选项、按需查找test_*.py文件findtests.py、并通过 worker 进程执行测试。仓库的 AGENTS.md 也印证了这一点并给出性能建议snippets 类测试用 debug 模式cargo run编译更快-m test的 unittest 套件用 release 模式cargo run --release运行性能更好。例如cargo run --release -- -m test test_unicode # 测试 test_unicode.py cargo run --release -- -m test test_unicode -k test_unicode_escape # 精确到某个函数对应的测试模块确实存在于仓库中如 Lib/test/test_io.py 与 Lib/test/test_codecs.py。第四步汇报结果测试跑完后SKILL.md 要求按以下要点汇报展示通过/失败汇总包括 expected failures预期失败即 CPython 中标记为已知失败或用例RustPython 复现相同行为与 unexpected successes意外成功即原本预期失败却通过了通常意味着某个功能刚被实现突出与 macOS 结果的对比如果已有 macOS 本机测试结果重点标出“新增失败”new failures即 Linux 容器中失败但在 macOS 上通过的用例——这类差异往往是平台相关行为而非解释器通用缺陷不要停止或删除容器测试结束后容器保持运行状态供后续多次测试复用。Notes容器管理的三条经验SKILL.md 末尾的 Notes 提供了三条经过实践沉淀的操作约定1. 任意容器内命令都用exec包裹container exec rustpython-test sh -c ...需要查看文件、安装工具或调试时统一用container exec rustpython-test sh -c ...形式执行任意命令避免绕过容器直接操作。2. 代码变更后重建container exec rustpython-test sh -c cargo build --release由于 bind mount 只同步源码Rust 二进制变更必须重新编译才能在容器内生效。改完 Rust 代码后先在容器内执行 release 构建再跑测试。3. 按需停止容器container rm -f rustpython-test只有用户明确要求时才执行container rm -f rustpython-test强制删除容器。默认策略是保留容器以复用已编译产物——重新构建rustpython-dev镜像和增量编译都很耗时保留容器能显著缩短后续迭代周期。完整工作流速查把四个步骤串联起来一次完整的 Linux 测试流程如下# 1. 检查容器是否在运行 container list 2/dev/null | grep rustpython-test # 2. 未运行时启动已运行则跳过 container run -d --name rustpython-test -m 8G -c 4 \ --mount typebind,source$(pwd),target/workspace \ -w /workspace rustpython-dev sleep infinity # 3. 执行测试 container exec rustpython-test cargo run --release -- -m test test_io -v # 4. 汇报汇总 pass/fail、expected failures、unexpected successes # 对比 macOS 结果突出新增失败容器保持运行 # 重建仅 Rust 代码变更后需要 container exec rustpython-test sh -c cargo build --release # 清理仅用户明确要求时 container rm -f rustpython-test与 RustPython 常规测试体系的关系这套容器工作流并非独立于项目而是 RustPython 多层级测试体系在 macOS 上的 Linux 补位。仓库的整体测试栈包括Rust 层测试cargo test --workspace覆盖 crates/vm 等 Rust crate 的单元测试AGENTS.md 要求改动后至少运行cargo test --workspace --exclude rustpython_wasm --exclude rustpython-venvlauncher --exclude rustpython-capiPython snippets 测试extra_tests/snippets/下的脚本用cargo run -- extra_tests/snippets/builtin_bytes.py或cd extra_tests pytest -v运行AGENTS.mdCPython 移植测试套件即本文主角cargo run --release -- -m test module驱动的Lib/test/regrtest 体系测试文件直接沿用 CPython 的test_*.py命名如 Lib/test/test_io.py、Lib/test/test_codecs.py由 Lib/test/libregrtest 这套 runner 调度。Applecontainer工作流把第三层测试搬到了 Linux 语义环境下执行让开发者在不离开 macOS 的前提下获得可靠的 Linux 对照基线。整个技能的核心价值可以概括为三点用 bind mount 实现源码即时同步、用固定容器名与sleep infinity保持可复用会话、用“测试后不删容器”的约定保护昂贵的编译产物。【免费下载链接】RustPythonA Python Interpreter written in Rust项目地址: https://gitcode.com/GitHub_Trending/ru/RustPython创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考