尧图网页设计 
开发工具CLI包管理器任务调度【免费下载链接】pixiPowerful system-level package manager for Linux, macOS and Windows written in Rust – building on top of the Conda ecosystem.项目地址https://gitcode.com/gh_mirrors/pi/pixi点击查看免费下载pixi-build-mojo是 Pixi 生态中专门为 Mojo 语言设计的构建后端它能在不手写recipe.yaml的前提下把 Mojo 项目自动生成成可安装、可发布的 Conda 包。本文以 docs/build/backends/pixi-build-mojo.md 为核心结合仓库内 pixi_build_mojo crate 的源码与测试系统讲解它的自动发现机制、全部配置项、编译器集成原理与调试方法。读完本文你将能直接从零配置一个 Mojo 项目用pixi install本地开发、用pixi publish发布到 Conda 渠道。前置条件开启pixi-build预览功能pixi-build目前仍处于预览阶段行为在稳定之前可能发生变化因此必须显式在pixi.toml的[workspace]表中声明启用[workspace] preview [pixi-build]这一步是使用任何构建后端包括pixi-build-mojo的前提缺失该声明时相关构建功能不会被激活。后端定位Mojo 项目与 Conda 包的桥梁pixi-build-mojo的核心职责是根据你的 Mojo 项目结构自动生成一份完整的 rattler-build recipe从而产出标准的 Conda 包。生成后的产物有两条去向安装到本地环境把包列为 workspace 的依赖后执行pixi install生成的二进制会进入$PREFIX/binMojo 包会进入$PREFIX/lib/mojo供其他依赖方发现打包分发执行pixi publish生成包含产物的 Conda 包并发布。从架构上看它属于 Pixi 的 build backend 协议实现详见 docs/build/backends.md后端是一个独立可执行程序与 Pixi 通过协议交互Pixi 把ProjectModel交给后端后端返回生成好的 recipe 与构建脚本再交给 rattler-build 执行。需要强调的是后端的行为不取决于 manifest 里声明的依赖——manifest 依赖只被转换成 recipe 的 requirements后端行为由[package.build.config]、项目文件和文件系统结构比如是否存在main.mojo共同决定。在仓库中该后端由pixi-build-mojocrate 实现核心入口是 crates/pixi_build_mojo/src/main.rs 中的MojoGenerator实现GenerateRecipetrait配置结构体MojoBackendConfig定义在 crates/pixi_build_mojo/src/config.rs。自动推导bins与pkg的智能发现这是pixi-build-mojo最省心的特性。后端会自动探测项目结构并推导以下两类产物Binaries可执行文件自动在project_root/main.mojo查找main.mojoPackagesMojo 包自动在以下位置按顺序查找包含__init__.mojo的目录project_root/project_name/project_root/src/因此在大多数情况下你无需显式配置bins或pkg字段。推导规则与 Caveats自动推导遵循一套明确的优先级规则对应源码 crates/pixi_build_mojo/src/config.rs 中的auto_derive实现如果bin和pkg都被自动推导出来则只创建bin此时必须手动指定pkg才会同时产出包如果用户手动指定了pkg则不再自动推导bin如果用户手动指定了bin则不再自动推导pkg如果既没有可推导的bin也没有pkg后端会直接报错No bin or pkg configuration detected.。从源码看MojoBinConfig::auto_derive与MojoPkgConfig::auto_derive分别实现各自的查找逻辑find_main仅检查root/main.mojo是否存在find_init_parent则按[project_name, src]顺序遍历并返回第一个存在__init__.mojo的目录。包/二进制名称默认取项目名且其中的连字符-会被替换为下划线_clean_project_name函数仓库中有专门的参数化测试覆盖my-project → my_project等转换场景。基本用法一个完整的 Mojo 项目示例下面是一个库 可执行文件组合项目的完整示例对应原文档的 Example project layout. ├── greetings │ ├── __init__.mojo │ └── lib.mojo ├── main.mojo ├── pixi.lock ├── pixi.toml └── README.md基于上述结构pixi-build-mojo会自动发现二进制来自根目录的main.mojo包来自greetings/__init__.mojo对应的最小配置[workspace] authors [J. Doe jdoemail.com] platforms [linux-64] preview [pixi-build] channels [ https://prefix.dev/conda-forge, https://conda.modular.com/max-nightly, https://prefix.dev/modular-community ] [package] name greetings version 0.1.0 [package.build] backend { name pixi-build-mojo, version 0.* } [tasks] [package.host-dependencies] mojo-compiler 25.5.0 [package.build-dependencies] mojo-compiler 25.5.0 small_time 25.4.1,26 extramojo 0.16.0,0.17 [package.run-dependencies] mojo-compiler 25.5.0 [dependencies] # For running mojo test while developing add all dependencies under # [package.build-dependencies] here as well. greetings { path . }配置要点说明[package.build]声明使用pixi-build-mojo后端version 0.*表示接受任意 0.x 版本mojo-compiler必须同时出现在host-dependencies、build-dependencies和run-dependencies中——它既承担编译任务也作为链接期和运行期的运行时依赖。原因详见下文「编译器集成」一节Mojo 编译器是特殊包不会通过通用的compilers机制自动注入开发时若想运行mojo test需要把[package.build-dependencies]中的依赖也在[dependencies]里声明一份并通过greetings { path . }把当前项目本身作为依赖引入本地环境。更多项目结构形态自动推导支持多种常见布局纯二进制项目根目录存在main.mojo即可. ├── main.mojo # Auto-derive as binary ├── pixi.toml └── README.md纯包项目目录名与项目名一致的包. ├── mypackage/ # Auto-derive if matches project name │ ├── __init__.mojo │ └── utils.mojo ├── pixi.toml └── README.mdsrc 目录布局src/下存在__init__.mojo. ├── src/ │ ├── __init__.mojo # Auto-derive as package │ └── lib.mojo ├── pixi.toml └── README.md组合项目前面已展示当main.mojo与greetings/__init__.mojo同时存在时按前述规则只自动推导bingreetings目录不会被自动推导为包. ├── greetings/ │ ├── __init__.mojo # NOT auto-derived as package │ └── lib.mojo ├── main.mojo # Auto-derived as binary ├── pixi.toml └── README.md必需依赖mojo/mojo-compiler编译器和链接运行时所必需的包。配置选项详解所有配置都写在[package.build.config]下后端支持以下选项。env类型MapString, String默认值{}构建过程中设置的环境变量。[package.build.config] env { ASSERT all }从源码看这些变量会被写入生成 recipe 的构建脚本环境见 crates/pixi_build_mojo/src/main.rs 中Script::from_content(...).with_env(...)因此可用于控制 Mojo 编译期的行为开关例如启用断言。debug-dir后端始终会把 JSON-RPC 请求/响应日志和生成的中间 recipe 写入工作目录下的debug子目录例如work_directory/debug具体到项目内通常是.pixi/build/work/package-name--hash/debug/参见 docs/build/backends.md 的 Troubleshooting 一节。遗留的debug-dir配置项已被废弃并忽略如果配置了它后端会发出警告提示其已不再生效。extra-input-globs类型ArrayString默认值[]额外的输入 glob用于让 Pixi 判断包是否需要重建。后端默认的输入 glob 只有**/*.mojo见MojoGenerator::globs()如果你在构建过程中还依赖其他类型的文件例如被extra-args引用的 C 头文件、资源文件等需要在这里显式声明否则这些文件的变更不会触发重建[package.build.config] extra-input-globs [**/*.c, assets/**/*, *.md]源码中extract_input_globs_from_build会把默认 glob 与extra_input_globs合并返回仓库内也有对应的单元测试test_input_globs_includes_extra_globs验证合并行为。compilers类型ArrayString默认值[]目标合并行为Overwrite—— 平台特定的编译器列表会整体替换基础配置要使用的编译器列表基于 conda-forge 的标准编译器基础设施平台映射表、构建变体机制、${{ compiler(c) }}等模板细节见 docs/build/key_concepts/compilers.md。[package.build.config] compilers [c, cxx]注意 Mojo 编译器的特殊行为compilers配置只负责注入 conda-forge 标准的编译器模板如 C/C/CUDA不会为你注入mojo-compiler。这正是默认值为[]的原因——mojo-compiler必须通过package.build-dependencies/host-dependencies/run-dependencies手动声明。这一点有源码与测试双重佐证在 crates/pixi_build_mojo/src/main.rs 的test_default_mojo_compiler_behavior中断言默认情况下没有任何${{ compiler(...) }}模板test_mojo_with_additional_compilers则验证配置[c, cxx]后恰好生成${{ compiler(c) }}与${{ compiler(cxx) }}两个模板且不会出现${{ compiler(mojo) }}。平台特定配置会整体覆盖基础配置[package.build.config] compilers [] [package.build.target.linux-64.config] compilers [c, cuda] # Result for linux-64: [mojo, c, cuda]上例注释中的mojo指手动声明在 build-dependencies 中的mojo-compiler而非编译器模板。在源码的merge_with_target_config实现中compilers字段的合并规则正是目标配置存在则整体替换。此外目标平台特定配置下env是平台覆盖同名、其余合并extra_input_globs则是平台整体替换。bins类型ArrayBinConfig默认值未指定时自动推导二进制配置列表。构建出的二进制会放在$PREFIX/bin目录下当包作为依赖如前面示例中的greetings { path . }被安装后执行pixi install即可在 PATH 中找到它。执行pixi publish会生成包含该二进制的 Conda 包。自动推导行为未指定bins时后端在项目根目录查找main.mojo找到后创建一个名称等于项目名的二进制如果pkg已被手动配置则不会自动推导bin需要手动配置。bins[].name类型String默认值第一个二进制的默认名为项目名连字符转换为下划线可执行文件名称。未指定时列表中第一个二进制默认取项目名额外的二进制此字段必填。[[package.build.config.bins]] # name greet # Optional for first binary, defaults to project name源码中MojoBinConfig::auto_derive会为第一个缺失name的二进制补上项目名并对所有配置项做名称冲突校验重复名称会报错Binary name has been used twice: ...见 config.rs 中的参数化测试。bins[].path类型String路径默认值第一个二进制自动推导包含main函数的 Mojo 文件路径。未指定时第一个二进制在项目根目录查找main.mojo额外的二进制此字段必填。[[package.build.config.bins]] # path ./main.mojo # Optional if main.mojo exists in project root若配置了二进制但根目录找不到main.mojo会直接报错Could not find main.mojo for configured binary。同时后端会把相对路径转换为绝对路径后再写入构建脚本make_paths_absolute测试test_relative_paths_are_made_absolute验证生成的脚本不会cd、且使用绝对路径避免工作目录变化导致路径失效。bins[].extra-args类型ArrayString默认值[]传给 Mojo 编译器的额外命令行参数构建该二进制时。[[package.build.config.bins]] extra-args [-I, special-thing]pkg类型PkgConfig默认值未指定时自动推导Mojo 包的配置。构建出的包放在$PREFIX/lib/mojo目录任何依赖该包的组件都能发现它。自动推导行为未指定pkg时按顺序查找包含__init__.mojo的目录project_root/project_name/project_root/src/找到后创建名称等于项目名的包找不到有效包目录时不构建包不报错如果bin已被手动配置则不会自动推导pkg如果bin也被自动推导了则不会生成pkg必须手动指定。pkg.name类型String默认值项目名连字符转换为下划线Mojo 包的名称。后端在使用mojo precompile时追加.mojoc后缀在回退到旧版mojo package命令时追加.mojopkg后缀。未指定时默认取项目名。[package.build.config.pkg] name greetingspkg.path类型String路径默认值自动推导构成包的目录路径。未指定时按上述顺序查找包含__init__.mojo的目录若找不到会报错Could not find valid package path for name。[package.build.config.pkg] path greetingspkg.extra-args类型ArrayString默认值[]构建该包时传给 Mojo 编译器的额外参数。[package.build.config.pkg] extra-args [-I, special-thing]默认 VariantsWindows 上的 Visual Studio 2022在 Windows 平台上后端会自动设置以下默认 variantsc_compilervs2022Visual Studio 2022 C 编译器cxx_compilervs2022Visual Studio 2022 C 编译器这些 variants 在配置[package.build.config.compilers]时生效。注意设置默认 variants 不会自动把编译器加入构建——你仍需显式配置要使用的编译器。该默认值来自pixi_build_backend::compilers::default_compiler_variants见 crates/pixi_build_mojo/src/main.rs 的default_variants实现对齐的是 conda-forge 切换到 Visual Studio 2022 的决策Visual Studio 2019 主流支持已于 2024 年结束vs2022在主流 CI runner 上支持更广。可以通过[workspace.build-variants]详见 docs/reference/pixi_manifest.md覆盖默认值例如回退到 vs2019[workspace.build-variants] c_compiler [vs2019] cxx_compiler [vs2019]更细粒度的平台覆盖可用[workspace.target.win.build-variants]相关示例见 docs/build/key_concepts/compilers.md。生成构建脚本的底层原理了解生成的构建脚本有助于排查问题。后端把bins/pkg渲染进一个 Jinja2 模板crates/pixi_build_mojo/src/build_script.j2渲染逻辑见 build_script.rs最终脚本大致如下mojo --version # 对每个 binmojo build extra-args path -o $PREFIX/bin/name # 对 pkg先探测编译器支持哪个子命令 if mojo precompile --help /dev/null 21; then MOJO_PKG_CMDprecompile MOJO_PKG_EXTmojoc else MOJO_PKG_CMDpackage MOJO_PKG_EXTmojopkg fi mkdir -p $PREFIX/lib/mojo mojo $MOJO_PKG_CMD extra-args path -o $PREFIX/lib/mojo/name.$MOJO_PKG_EXT几个值得注意的实现细节子命令探测Mojo v1.0 把mojo package重命名为mojo precompile因此脚本在运行时通过mojo precompile --help探测当前编译器支持哪个子命令再决定用.mojoc新还是.mojopkg旧后缀——这让后端能同时兼容新旧版 Mojo 编译器build_script.rs 中有对应的快照测试pkg_selects_matching_command_and_extension输出位置二进制固定输出到$PREFIX/binMojo 包固定输出到$PREFIX/lib/mojo路径绝对化所有bin.path/pkg.path在写入脚本前都会被转换为绝对路径env 注入config.env中的键值对会被写入脚本环境。调试与重建当构建出现问题例如pixi publish失败时可以直接检查后端生成的完整 rattler-build recipe位置在项目的构建工作目录下your_project/.pixi/build/work/package-name--hash/debug/该目录包含recipe.yaml—— 后端生成的完整 rattler-build recipevariant_hash子目录下还有针对单个 variant 的具体版本variants.yaml—— 变体配置project_model.json、*_params.json、*_response.json—— JSON-RPC 请求/响应日志可用于核对传给后端的项目模型。重建方式二选一# 方式一进入 recipe 目录 cd .pixi/build/work/package-name--hash/recipe/variant_hash/debug/ rattler-build build # 方式二直接指定 recipe 目录 rattler-build build --recipe .pixi/build/work/package-name--hash/debug/recipe/variant_hash/调试时注意debug-dir配置项已被忽略日志始终写入上述debug子目录。常见注意事项速查忘记在[workspace]中声明preview [pixi-build]构建功能不会启用mojo-compiler必须手动声明在build-dependencies以及需要时的host-dependencies/run-dependencies中它不会由compilers选项自动注入同时自动推导出 bin 和 pkg 时只保留 bin需要 pkg 请手动配置手动配置pkg或bin中的任意一个都会抑制另一个的自动推导bin/pkg的name默认取项目名连字符自动转下划线多二进制/多产物场景下除第一个 bin 外name与path均为必填构建输入 glob 默认只有**/*.mojo依赖其他类型文件头文件、资源时要通过extra-input-globs补充否则文件变更不会触发重建。相关资源后端完整配置与行为定义docs/build/backends/pixi-build-mojo.md编译器与构建变体机制docs/build/key_concepts/compilers.md后端协议与调试总览docs/build/backends.md配置结构体与自动推导实现crates/pixi_build_mojo/src/config.rs构建脚本模板crates/pixi_build_mojo/src/build_script.j2recipe 生成入口与测试crates/pixi_build_mojo/src/main.rs生成结果的快照示例crates/pixi_build_mojo/src/snapshots赞分享开发工具CLI包管理器任务调度【免费下载链接】pixiPowerful system-level package manager for Linux, macOS and Windows written in Rust – building on top of the Conda ecosystem.项目地址https://gitcode.com/gh_mirrors/pi/pixi点击查看免费下载相关推荐pixi-build-python 构建后端深度指南用 Pixi 将 PEP 517/518 Python 项目一键打包为 conda 包pixi build python 构建后端深度指南用 Pixi 将 PEP 517/518 Python 项目一键打包为 conda 包 Pixi 的 pi开发工具CLI包管理器任务调度Pixi 构建后端 pixi-build-rust用 Cargo 自动生成 Conda 包Pixi 构建后端 pixi build rust用 Cargo 自动生成 Conda 包 pixi build rust 是 Pixi 的 Rust 项目构开发工具CLI包管理器任务调度抖音视频批量下载指南无水印、主页全量、增量同步抖音视频批量下载指南无水印、主页全量、增量同步 你想把某个博主的主页作品一次存全又怕重下、带水印抖音视频批量下载工具 douyin downloader开发工具CLI包管理器任务调度上一篇5分钟掌握游戏手柄性能检测用XInputTest免费测量延迟与轮询率下一篇打破数据壁垒华为运动数据TCX转换器使用指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 pixi-build-mojo 后端详解：使用 Pixi 将 Mojo 项目构建为 Conda 包
开发工具CLI包管理器任务调度【免费下载链接】pixiPowerful system-level package manager for Linux, macOS and Windows written in Rust – building on top of the Conda ecosystem.项目地址https://gitcode.com/gh_mirrors/pi/pixi点击查看免费下载pixi-build-mojo是 Pixi 生态中专门为 Mojo 语言设计的构建后端它能在不手写recipe.yaml的前提下把 Mojo 项目自动生成成可安装、可发布的 Conda 包。本文以 docs/build/backends/pixi-build-mojo.md 为核心结合仓库内 pixi_build_mojo crate 的源码与测试系统讲解它的自动发现机制、全部配置项、编译器集成原理与调试方法。读完本文你将能直接从零配置一个 Mojo 项目用pixi install本地开发、用pixi publish发布到 Conda 渠道。前置条件开启pixi-build预览功能pixi-build目前仍处于预览阶段行为在稳定之前可能发生变化因此必须显式在pixi.toml的[workspace]表中声明启用[workspace] preview [pixi-build]这一步是使用任何构建后端包括pixi-build-mojo的前提缺失该声明时相关构建功能不会被激活。后端定位Mojo 项目与 Conda 包的桥梁pixi-build-mojo的核心职责是根据你的 Mojo 项目结构自动生成一份完整的 rattler-build recipe从而产出标准的 Conda 包。生成后的产物有两条去向安装到本地环境把包列为 workspace 的依赖后执行pixi install生成的二进制会进入$PREFIX/binMojo 包会进入$PREFIX/lib/mojo供其他依赖方发现打包分发执行pixi publish生成包含产物的 Conda 包并发布。从架构上看它属于 Pixi 的 build backend 协议实现详见 docs/build/backends.md后端是一个独立可执行程序与 Pixi 通过协议交互Pixi 把ProjectModel交给后端后端返回生成好的 recipe 与构建脚本再交给 rattler-build 执行。需要强调的是后端的行为不取决于 manifest 里声明的依赖——manifest 依赖只被转换成 recipe 的 requirements后端行为由[package.build.config]、项目文件和文件系统结构比如是否存在main.mojo共同决定。在仓库中该后端由pixi-build-mojocrate 实现核心入口是 crates/pixi_build_mojo/src/main.rs 中的MojoGenerator实现GenerateRecipetrait配置结构体MojoBackendConfig定义在 crates/pixi_build_mojo/src/config.rs。自动推导bins与pkg的智能发现这是pixi-build-mojo最省心的特性。后端会自动探测项目结构并推导以下两类产物Binaries可执行文件自动在project_root/main.mojo查找main.mojoPackagesMojo 包自动在以下位置按顺序查找包含__init__.mojo的目录project_root/project_name/project_root/src/因此在大多数情况下你无需显式配置bins或pkg字段。推导规则与 Caveats自动推导遵循一套明确的优先级规则对应源码 crates/pixi_build_mojo/src/config.rs 中的auto_derive实现如果bin和pkg都被自动推导出来则只创建bin此时必须手动指定pkg才会同时产出包如果用户手动指定了pkg则不再自动推导bin如果用户手动指定了bin则不再自动推导pkg如果既没有可推导的bin也没有pkg后端会直接报错No bin or pkg configuration detected.。从源码看MojoBinConfig::auto_derive与MojoPkgConfig::auto_derive分别实现各自的查找逻辑find_main仅检查root/main.mojo是否存在find_init_parent则按[project_name, src]顺序遍历并返回第一个存在__init__.mojo的目录。包/二进制名称默认取项目名且其中的连字符-会被替换为下划线_clean_project_name函数仓库中有专门的参数化测试覆盖my-project → my_project等转换场景。基本用法一个完整的 Mojo 项目示例下面是一个库 可执行文件组合项目的完整示例对应原文档的 Example project layout. ├── greetings │ ├── __init__.mojo │ └── lib.mojo ├── main.mojo ├── pixi.lock ├── pixi.toml └── README.md基于上述结构pixi-build-mojo会自动发现二进制来自根目录的main.mojo包来自greetings/__init__.mojo对应的最小配置[workspace] authors [J. Doe jdoemail.com] platforms [linux-64] preview [pixi-build] channels [ https://prefix.dev/conda-forge, https://conda.modular.com/max-nightly, https://prefix.dev/modular-community ] [package] name greetings version 0.1.0 [package.build] backend { name pixi-build-mojo, version 0.* } [tasks] [package.host-dependencies] mojo-compiler 25.5.0 [package.build-dependencies] mojo-compiler 25.5.0 small_time 25.4.1,26 extramojo 0.16.0,0.17 [package.run-dependencies] mojo-compiler 25.5.0 [dependencies] # For running mojo test while developing add all dependencies under # [package.build-dependencies] here as well. greetings { path . }配置要点说明[package.build]声明使用pixi-build-mojo后端version 0.*表示接受任意 0.x 版本mojo-compiler必须同时出现在host-dependencies、build-dependencies和run-dependencies中——它既承担编译任务也作为链接期和运行期的运行时依赖。原因详见下文「编译器集成」一节Mojo 编译器是特殊包不会通过通用的compilers机制自动注入开发时若想运行mojo test需要把[package.build-dependencies]中的依赖也在[dependencies]里声明一份并通过greetings { path . }把当前项目本身作为依赖引入本地环境。更多项目结构形态自动推导支持多种常见布局纯二进制项目根目录存在main.mojo即可. ├── main.mojo # Auto-derive as binary ├── pixi.toml └── README.md纯包项目目录名与项目名一致的包. ├── mypackage/ # Auto-derive if matches project name │ ├── __init__.mojo │ └── utils.mojo ├── pixi.toml └── README.mdsrc 目录布局src/下存在__init__.mojo. ├── src/ │ ├── __init__.mojo # Auto-derive as package │ └── lib.mojo ├── pixi.toml └── README.md组合项目前面已展示当main.mojo与greetings/__init__.mojo同时存在时按前述规则只自动推导bingreetings目录不会被自动推导为包. ├── greetings/ │ ├── __init__.mojo # NOT auto-derived as package │ └── lib.mojo ├── main.mojo # Auto-derived as binary ├── pixi.toml └── README.md必需依赖mojo/mojo-compiler编译器和链接运行时所必需的包。配置选项详解所有配置都写在[package.build.config]下后端支持以下选项。env类型MapString, String默认值{}构建过程中设置的环境变量。[package.build.config] env { ASSERT all }从源码看这些变量会被写入生成 recipe 的构建脚本环境见 crates/pixi_build_mojo/src/main.rs 中Script::from_content(...).with_env(...)因此可用于控制 Mojo 编译期的行为开关例如启用断言。debug-dir后端始终会把 JSON-RPC 请求/响应日志和生成的中间 recipe 写入工作目录下的debug子目录例如work_directory/debug具体到项目内通常是.pixi/build/work/package-name--hash/debug/参见 docs/build/backends.md 的 Troubleshooting 一节。遗留的debug-dir配置项已被废弃并忽略如果配置了它后端会发出警告提示其已不再生效。extra-input-globs类型ArrayString默认值[]额外的输入 glob用于让 Pixi 判断包是否需要重建。后端默认的输入 glob 只有**/*.mojo见MojoGenerator::globs()如果你在构建过程中还依赖其他类型的文件例如被extra-args引用的 C 头文件、资源文件等需要在这里显式声明否则这些文件的变更不会触发重建[package.build.config] extra-input-globs [**/*.c, assets/**/*, *.md]源码中extract_input_globs_from_build会把默认 glob 与extra_input_globs合并返回仓库内也有对应的单元测试test_input_globs_includes_extra_globs验证合并行为。compilers类型ArrayString默认值[]目标合并行为Overwrite—— 平台特定的编译器列表会整体替换基础配置要使用的编译器列表基于 conda-forge 的标准编译器基础设施平台映射表、构建变体机制、${{ compiler(c) }}等模板细节见 docs/build/key_concepts/compilers.md。[package.build.config] compilers [c, cxx]注意 Mojo 编译器的特殊行为compilers配置只负责注入 conda-forge 标准的编译器模板如 C/C/CUDA不会为你注入mojo-compiler。这正是默认值为[]的原因——mojo-compiler必须通过package.build-dependencies/host-dependencies/run-dependencies手动声明。这一点有源码与测试双重佐证在 crates/pixi_build_mojo/src/main.rs 的test_default_mojo_compiler_behavior中断言默认情况下没有任何${{ compiler(...) }}模板test_mojo_with_additional_compilers则验证配置[c, cxx]后恰好生成${{ compiler(c) }}与${{ compiler(cxx) }}两个模板且不会出现${{ compiler(mojo) }}。平台特定配置会整体覆盖基础配置[package.build.config] compilers [] [package.build.target.linux-64.config] compilers [c, cuda] # Result for linux-64: [mojo, c, cuda]上例注释中的mojo指手动声明在 build-dependencies 中的mojo-compiler而非编译器模板。在源码的merge_with_target_config实现中compilers字段的合并规则正是目标配置存在则整体替换。此外目标平台特定配置下env是平台覆盖同名、其余合并extra_input_globs则是平台整体替换。bins类型ArrayBinConfig默认值未指定时自动推导二进制配置列表。构建出的二进制会放在$PREFIX/bin目录下当包作为依赖如前面示例中的greetings { path . }被安装后执行pixi install即可在 PATH 中找到它。执行pixi publish会生成包含该二进制的 Conda 包。自动推导行为未指定bins时后端在项目根目录查找main.mojo找到后创建一个名称等于项目名的二进制如果pkg已被手动配置则不会自动推导bin需要手动配置。bins[].name类型String默认值第一个二进制的默认名为项目名连字符转换为下划线可执行文件名称。未指定时列表中第一个二进制默认取项目名额外的二进制此字段必填。[[package.build.config.bins]] # name greet # Optional for first binary, defaults to project name源码中MojoBinConfig::auto_derive会为第一个缺失name的二进制补上项目名并对所有配置项做名称冲突校验重复名称会报错Binary name has been used twice: ...见 config.rs 中的参数化测试。bins[].path类型String路径默认值第一个二进制自动推导包含main函数的 Mojo 文件路径。未指定时第一个二进制在项目根目录查找main.mojo额外的二进制此字段必填。[[package.build.config.bins]] # path ./main.mojo # Optional if main.mojo exists in project root若配置了二进制但根目录找不到main.mojo会直接报错Could not find main.mojo for configured binary。同时后端会把相对路径转换为绝对路径后再写入构建脚本make_paths_absolute测试test_relative_paths_are_made_absolute验证生成的脚本不会cd、且使用绝对路径避免工作目录变化导致路径失效。bins[].extra-args类型ArrayString默认值[]传给 Mojo 编译器的额外命令行参数构建该二进制时。[[package.build.config.bins]] extra-args [-I, special-thing]pkg类型PkgConfig默认值未指定时自动推导Mojo 包的配置。构建出的包放在$PREFIX/lib/mojo目录任何依赖该包的组件都能发现它。自动推导行为未指定pkg时按顺序查找包含__init__.mojo的目录project_root/project_name/project_root/src/找到后创建名称等于项目名的包找不到有效包目录时不构建包不报错如果bin已被手动配置则不会自动推导pkg如果bin也被自动推导了则不会生成pkg必须手动指定。pkg.name类型String默认值项目名连字符转换为下划线Mojo 包的名称。后端在使用mojo precompile时追加.mojoc后缀在回退到旧版mojo package命令时追加.mojopkg后缀。未指定时默认取项目名。[package.build.config.pkg] name greetingspkg.path类型String路径默认值自动推导构成包的目录路径。未指定时按上述顺序查找包含__init__.mojo的目录若找不到会报错Could not find valid package path for name。[package.build.config.pkg] path greetingspkg.extra-args类型ArrayString默认值[]构建该包时传给 Mojo 编译器的额外参数。[package.build.config.pkg] extra-args [-I, special-thing]默认 VariantsWindows 上的 Visual Studio 2022在 Windows 平台上后端会自动设置以下默认 variantsc_compilervs2022Visual Studio 2022 C 编译器cxx_compilervs2022Visual Studio 2022 C 编译器这些 variants 在配置[package.build.config.compilers]时生效。注意设置默认 variants 不会自动把编译器加入构建——你仍需显式配置要使用的编译器。该默认值来自pixi_build_backend::compilers::default_compiler_variants见 crates/pixi_build_mojo/src/main.rs 的default_variants实现对齐的是 conda-forge 切换到 Visual Studio 2022 的决策Visual Studio 2019 主流支持已于 2024 年结束vs2022在主流 CI runner 上支持更广。可以通过[workspace.build-variants]详见 docs/reference/pixi_manifest.md覆盖默认值例如回退到 vs2019[workspace.build-variants] c_compiler [vs2019] cxx_compiler [vs2019]更细粒度的平台覆盖可用[workspace.target.win.build-variants]相关示例见 docs/build/key_concepts/compilers.md。生成构建脚本的底层原理了解生成的构建脚本有助于排查问题。后端把bins/pkg渲染进一个 Jinja2 模板crates/pixi_build_mojo/src/build_script.j2渲染逻辑见 build_script.rs最终脚本大致如下mojo --version # 对每个 binmojo build extra-args path -o $PREFIX/bin/name # 对 pkg先探测编译器支持哪个子命令 if mojo precompile --help /dev/null 21; then MOJO_PKG_CMDprecompile MOJO_PKG_EXTmojoc else MOJO_PKG_CMDpackage MOJO_PKG_EXTmojopkg fi mkdir -p $PREFIX/lib/mojo mojo $MOJO_PKG_CMD extra-args path -o $PREFIX/lib/mojo/name.$MOJO_PKG_EXT几个值得注意的实现细节子命令探测Mojo v1.0 把mojo package重命名为mojo precompile因此脚本在运行时通过mojo precompile --help探测当前编译器支持哪个子命令再决定用.mojoc新还是.mojopkg旧后缀——这让后端能同时兼容新旧版 Mojo 编译器build_script.rs 中有对应的快照测试pkg_selects_matching_command_and_extension输出位置二进制固定输出到$PREFIX/binMojo 包固定输出到$PREFIX/lib/mojo路径绝对化所有bin.path/pkg.path在写入脚本前都会被转换为绝对路径env 注入config.env中的键值对会被写入脚本环境。调试与重建当构建出现问题例如pixi publish失败时可以直接检查后端生成的完整 rattler-build recipe位置在项目的构建工作目录下your_project/.pixi/build/work/package-name--hash/debug/该目录包含recipe.yaml—— 后端生成的完整 rattler-build recipevariant_hash子目录下还有针对单个 variant 的具体版本variants.yaml—— 变体配置project_model.json、*_params.json、*_response.json—— JSON-RPC 请求/响应日志可用于核对传给后端的项目模型。重建方式二选一# 方式一进入 recipe 目录 cd .pixi/build/work/package-name--hash/recipe/variant_hash/debug/ rattler-build build # 方式二直接指定 recipe 目录 rattler-build build --recipe .pixi/build/work/package-name--hash/debug/recipe/variant_hash/调试时注意debug-dir配置项已被忽略日志始终写入上述debug子目录。常见注意事项速查忘记在[workspace]中声明preview [pixi-build]构建功能不会启用mojo-compiler必须手动声明在build-dependencies以及需要时的host-dependencies/run-dependencies中它不会由compilers选项自动注入同时自动推导出 bin 和 pkg 时只保留 bin需要 pkg 请手动配置手动配置pkg或bin中的任意一个都会抑制另一个的自动推导bin/pkg的name默认取项目名连字符自动转下划线多二进制/多产物场景下除第一个 bin 外name与path均为必填构建输入 glob 默认只有**/*.mojo依赖其他类型文件头文件、资源时要通过extra-input-globs补充否则文件变更不会触发重建。相关资源后端完整配置与行为定义docs/build/backends/pixi-build-mojo.md编译器与构建变体机制docs/build/key_concepts/compilers.md后端协议与调试总览docs/build/backends.md配置结构体与自动推导实现crates/pixi_build_mojo/src/config.rs构建脚本模板crates/pixi_build_mojo/src/build_script.j2recipe 生成入口与测试crates/pixi_build_mojo/src/main.rs生成结果的快照示例crates/pixi_build_mojo/src/snapshots赞分享开发工具CLI包管理器任务调度【免费下载链接】pixiPowerful system-level package manager for Linux, macOS and Windows written in Rust – building on top of the Conda ecosystem.项目地址https://gitcode.com/gh_mirrors/pi/pixi点击查看免费下载相关推荐pixi-build-python 构建后端深度指南用 Pixi 将 PEP 517/518 Python 项目一键打包为 conda 包pixi build python 构建后端深度指南用 Pixi 将 PEP 517/518 Python 项目一键打包为 conda 包 Pixi 的 pi开发工具CLI包管理器任务调度Pixi 构建后端 pixi-build-rust用 Cargo 自动生成 Conda 包Pixi 构建后端 pixi build rust用 Cargo 自动生成 Conda 包 pixi build rust 是 Pixi 的 Rust 项目构开发工具CLI包管理器任务调度抖音视频批量下载指南无水印、主页全量、增量同步抖音视频批量下载指南无水印、主页全量、增量同步 你想把某个博主的主页作品一次存全又怕重下、带水印抖音视频批量下载工具 douyin downloader开发工具CLI包管理器任务调度上一篇5分钟掌握游戏手柄性能检测用XInputTest免费测量延迟与轮询率下一篇打破数据壁垒华为运动数据TCX转换器使用指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考