mise 内置 Homebrew 后端：无需安装 brew 即可安装 formulae 与 casks

mise 的 bootstrap packages 体系在 brew: 与 brew-cask: 两个管理器下，实现了不依赖 Homebrew 本体即可将 homebrew/core 的 formulae 直接灌入规范前缀（macOS arm64 的 /opt/homebrew、Linux 的 /home/linuxbrew/.linuxbrew），并安装 cask 应用。本文完整覆盖配置写法、首装流程、tap 支持、cask 的 adopt/appdir 语义、前缀布局、与真实 Homebrew 的共存机制、pouring 与源码构建原理、导入/清理及升级命令，并附仓库源码证据，读者读完可以独立用 mise 复刻 Homebrew 的声明式包管理体验。

概览：mise 如何"无 brew 安装 brew 包"

在 docs/bootstrap/packages/brew.md 中，Homebrew 后端被定义为 无需安装 Homebrew 即可安装 formulae 与 casks。它的核心思路是：

• 从 formulae.brew.sh API 拉取元数据（src/system/packages/brew/api.rs、src/system/packages/brew/cask/fetch.rs 中 API_BASE: &str = "https://formulae.brew.sh/api"）；
• 解析运行时依赖闭包；
• 从 ghcr.io 下载预编译 bottle 并校验 sha256；
• 执行与 brew pouring 相同的 relocation（重定位）、代码签名与链接工作。

其模块化实现位于 src/system/packages/brew/mod.rs（BrewManager）与 src/system/packages/brew/cask/mod.rs（BrewCaskManager），源码头部注释明确写着 "Homebrew formulae without Homebrew"（不需要 Homebrew 的 Homebrew formulae）。关键承诺是：对于 homebrew/core formulae，mise 从不 shell out 调用 brew 命令。

最基本的使用方式是声明 [bootstrap.packages]：

[bootstrap.packages]
"brew:postgresql@17" = "latest"
"brew:ffmpeg" = "latest"
"brew:imagemagick" = "latest"
"brew-cask:firefox" = "latest"

注意：这里的 @17 是公式名的一部分（postgresql 的多版本公式名），不是 mise 的版本 pin。mise 不按版本 pin 安装 brew 包，安装版本由 API 当前的 stable 版本决定。这与其 supports_version_pins() -> false 的实现一致（src/system/packages/brew/mod.rs）。

与工具后端的分工

文档强调了一个使用边界：这些包声明不会创建 mise shim，也不会修改当前 shell 的 PATH。它们面向"软件放在共享 Homebrew 前缀"的场景；若你需要项目级版本切换的 CLI，应使用 工具后端（如 mise use -g node@22 这类 tool backend）。两者各司其职，不要混淆。

首次安装：三连命令

首装流程遵循 bootstrap packages 的通用三阶段：

mise bootstrap packages status
mise bootstrap packages apply --manager brew --dry-run
mise bootstrap packages apply --manager brew

• status：查看声明条目与当前安装状态的对比；
• apply --dry-run：预览将要执行的动作，不落地；
• apply：真正执行安装。

安装前请先核对下文 支持的平台 表格。需要注意：源码构建需要编译器与构建工具（macOS 需要 Xcode Command Line Tools，Linux 需要 gcc/make）；部分 cask 需要写系统目录的权限（会有 sudo 提权）；一次安装可能连带安装该包的依赖。

第三方 tap

mise 支持与传给 Homebrew 完全一致的全限定名：

[bootstrap.packages]
"brew:owner/tap/formula" = "latest"
"brew-cask:owner/tap/app" = "latest"

解析顺序（源码可见于 src/system/packages/brew/tap.rs）：

1. 先查找 tap 发布的 Homebrew API 元数据（api/formula/<name>.json 或 api/cask/<token>.json）；
2. 若 tap 未发布元数据，则拉取固定 tap commit 上的 Ruby 定义，用 mise 自己的 Formula/Cask DSL shim（src/system/packages/brew/shim.rb、cask_shim.rb、tap_formula_metadata.rb、tap_cask_metadata.rb）评估其元数据。

公式定义按 Homebrew 的目录级优先级发现：Formula/ → HomebrewFormula/ → 仓库根。前两个目录支持嵌套公式，根级发现仅限顶层。以此方式解析的公式从源码构建。shim 覆盖常用 DSL，无法安全评估或安装的定义会明确报错。整个过程中 mise 不会调用或安装 Homebrew。

对于无法推断出 GitHub URL 的 tap，可显式添加 tap 源——这与 [plugins] 的写法对称：key 是 tap 名，value 是 GitHub git URL：

[bootstrap.brew.taps]
"acme/tools" = "https://github.com/acme/homebrew-tools.git"

[bootstrap.packages]
"brew:acme/tools/widget" = "latest"
"brew-cask:acme/tools/widget-app" = "latest"

对应的 CLI 管理命令是 mise bootstrap packages brew tap 与 mise bootstrap packages brew untap（实现于 src/cli/system/brew/tap.rs）。它们只操作 mise.toml 中的 [bootstrap.brew.taps]，不会改动真实 Homebrew 安装：

mise bootstrap packages brew tap railwaycat/emacsmacport
mise bootstrap packages brew tap acme/tools https://github.com/acme/homebrew-tools.git
mise bootstrap packages brew untap acme/tools

限制：非 GitHub 托管的 tap 目前不受支持，因为 mise 需要直接 raw 访问 tap 元数据与 Ruby 定义。

Casks

Cask 使用 brew-cask: 管理器。安装流程：从 Homebrew cask API（或 tap API 元数据）获取 cask 元数据 → 下载工件 → 校验 sha256（若 cask 提供）→ 解压归档 → 将 app bundle 安装到 /Applications，同时在 <prefix>/Caskroom 记录版本。对于普通受管 app 工件，mise 将 bundle 移入 /Applications，并在版本化 Caskroom 路径留下符号链接，避免保留第二份应用副本。

[bootstrap.packages]
"brew-cask:firefox" = "latest"
"brew-cask:homebrew/cask/visual-studio-code" = "latest"

覆盖应用目录（MISE_BREW_CASK_OPT_APPDIR）

默认 app 工件安装到 /Applications（与 Homebrew 一致）。设置 MISE_BREW_CASK_OPT_APPDIR 环境变量可改到别处——例如无需提权的用户可写目录 ~/Applications：

MISE_BREW_CASK_OPT_APPDIR="$HOME/Applications" mise bootstrap packages apply brew-cask:firefox

其语义（源码见 src/system/packages/brew/cask/paths.rs 与 src/system/packages/brew/cask/mod.rs，常量 APP_DIR_ENV = "MISE_BREW_CASK_OPT_APPDIR"、DEFAULT_APP_DIR = "/Applications"）：

• 值必须是绝对路径，不得包含 ..，不得解析为文件系统根；
• 使用前会解析为真实路径（跟随符号链接），因此它构成 mise 创建的应用链接的固定围栏边界；
• 空值被忽略并回退到 /Applications；
• 设置了覆盖后，目标为默认 /Applications 的 cask（绝大多数）会被重定位进覆盖目录，保留 cask 要求的子目录；锚定在 $HOMEBREW_PREFIX/Applications 下的目标留在 Homebrew 前缀内，永不被重定位。

这镜像了 Homebrew 自己的 brew install --cask --appdir 选项。

adopt：收养已存在的应用

若 cask 目标位置已有应用，用表形式声明 adopt = true 来收养它：

[bootstrap.packages]
"brew-cask:textmate" = { version = "latest", adopt = true }

也可以在 [bootstrap.brew] 里为所有 cask 打开收养默认值，个别 cask 用 adopt = false 退出：

[bootstrap.brew]
adopt = true

[bootstrap.packages]
"brew-cask:textmate" = "latest"
"brew-cask:replace-me" = { adopt = false }

行为与 brew install --cask --adopt 一致：mise 下载并校验当前 cask 工件，仅当现有应用内容完全一致时才收养；若现有应用不同，则保持不动并让安装失败。例外是声明 auto_updates: true 的 cask：与 Homebrew 一致，这类 cask 直接按原样收养现有应用，因为它可能已经自我更新过。被收养的应用由 mise receipt 追踪，Caskroom 中不再保留重复的 app bundle。

auto_updates 语义

元数据声明 auto_updates: true 的 cask 安装当前版本后交给应用自行更新。mise 不暴露 auto_updates 覆盖项：cask 定义保持权威。这类自更新应用同样只被 receipt 追踪，不留重复 Caskroom bundle。安装/apply 及依赖安装都保持已安装的自更新应用不变。

显式 mise bootstrap packages upgrade 遵循 Homebrew 的默认决策：

• latest 及 receipt 版本匹配的跳过；
• 否则，拥有单个 app 的 cask 只有在实时 CFBundleShortVersionString 与 CFBundleVersion 显示更旧版本时才升级（使用 Homebrew 的比较规则，含 CSV 与 combined short/build 版本）；
• 当前版、更新版、不可读或不可比较的应用版本跳过替换；
• 下载并获取安装锁后 mise 会再检查一次——外部自更新器仍可能在检查与替换之间改掉应用；dry-run 只报告决策不替换。

mise bootstrap status 将此类条目标记为 installed (auto-updates)。对 mise 拥有的 cask，Current 列是 mise receipt 中记录的版本，实时应用可能已自更新到不同版本。JSON 状态保持稳定的 "state": "installed" 并新增 "auto_updates": true。

macOS Privacy & Security（TCC）

替换 /Applications（或配置的 appdir）下的 app bundle，与 brew reinstall --cask 属于同一类操作：macOS 可能撤销该应用的隐私与安全授权（辅助功能、屏幕录制、完全磁盘访问、自动化等）。mise 不管理 TCC；替换后你可能需要在系统设置里重新授权。

迁移没有 Homebrew .metadata 的未托管应用时，优先用 adoption，让 mise 记录所有权而无需替换实时 bundle：

[bootstrap.brew]
adopt = true

或选择性收养：

[bootstrap.packages]
"brew-cask:firefox" = { version = "latest", adopt = true }

mise 每次替换现有 .app 都会打印警告。版本升级在上游发布新 cask 版本时仍会替换 bundle——和 Homebrew 一样，升级后需要重新确认 TCC 弹窗。

Linux 字体 cask

在 Linux 上，cask 支持仅限于纯字体 cask（无生命周期钩子、无结构化 preflight_steps/postflight_steps——这些是 Homebrew cask DSL 的概念）。字体安装到 $XDG_DATA_HOME/fonts（默认 ~/.local/share/fonts）：

[bootstrap.packages]
"brew-cask:font-heavy-data-nerd-font" = "latest"

来自 [bootstrap.packages] 的其他 Linux cask 会被报告为不可用并跳过，因此 macOS 与 Linux 可以共享同一份包列表。显式请求（如 mise bootstrap packages apply brew-cask:firefox）仍会以清晰的 unsupported-platform 错误失败。也可用 { os = "macos" } 显式标记 macOS cask。该边界会随 mise 实现更多可移植的 cask 工件类型而扩展。

支持的工件与生命周期动作

brew-cask 目前支持：

• app-bundle cask（app 工件）；
• 二进制与生成的命令包装 cask（binary、command_wrapper 工件）；
• 通用前缀工件（artifact）；
• 字体工件（font）；
• 简单 macOS 安装器包（pkg 工件）；
• 基于脚本的 cask 安装器；
• shell 补全（bash_completion、fish_completion、zsh_completion、generate_completions_from_executable），支持来自 dmg 与常见归档格式。

二进制工件与生成的包装器在 Caskroom 暂存，然后链接进 Homebrew 前缀（通常在 <prefix>/bin）。包安装器走 mise 常规的 system-package sudo 路径，所以非交互运行不会挂起等密码。pkg cask 必须在 uninstall 元数据中包含 pkgutil receipt ID，以便安装器在 Caskroom 之外写文件后 mise 能校验安装状态；zap 的 pkgutil ID 仅视为清理元数据而非安装 receipt。

对有生命周期钩子的 cask，mise 拉取 API 元数据钉住的、经 sha256 校验的 cask Ruby 源码，通过自己的 Cask DSL shim 运行受支持的 preflight/postflight 钩子（源码见 src/system/packages/brew/cask/flight.rs），不委托 Homebrew。还支持结构化 preflight_steps/postflight_steps：

• move/remove：针对 staged_path 的操作；
• run：使用 Homebrew 的序列化命令基、参数、环境、guards 与 sudo 设置；
• terminate_process：Homebrew 兼容的名称/完整匹配、重试、通知与失败策略；
• copy/symlink：支持 Homebrew 路径基、模板、guards、源 glob、替换与 sudo 行为。

生命周期步骤创建的外部路径会记入 mise receipt，安装事务失败时恢复。cask 的公式与 cask 依赖先安装，声明的 cask 冲突在任何修改前失败。需要自定义安装选项、services、不受支持的钩子 DSL、不受支持的结构化生命周期步骤或其他工件类型的 cask，会以清晰的 unsupported artifact 错误失败，而不是委托 Homebrew。

所有权与安装状态

直接 cask pour 归 mise 所有，完成状态记录在 .mise-cask.toml；mise 不合成 Homebrew 私有的 .metadata receipt。带 .metadata 且只有一个 Caskroom 版本的 Homebrew 自有 cask，可以满足匹配的 brew-cask: 条目而无需转移所有权：status 报告为已安装并以该 Caskroom 目录名作为 Current 版本；apply 保持不动；upgrade 跳过其生命周期。mise 不创建 .mise-cask.toml、不收养、不改元数据、不改 app 目标、前缀二进制或补全链接——请用 Homebrew 升级、重装或移除它。若 Homebrew 元数据无版本或有多个版本，mise 会以 Homebrew 修复指引失败，而不是猜测哪个安装有效。

对 mise 拥有的 cask，status 在 receipt 与记录目标仍存在时视为已安装。app 与字体内容指纹用于 prune 与 adopt 安全，但现有 app/字体内部的内容漂移不会标记 cask 缺失，也不会在 apply 时触发重装——替换 /Applications/*.app 会重置 macOS TCC 授权。二进制与补全符号链接仍要求记录的目标链接（廉价 readlink）与可解析目标，悬空或被重定向的链接保持可修复。缺失或未知 receipt、待处理事务仍报告为 unhealthy，以便下次 apply 调和。版本升级与显式 remove + apply 在你想全新 pouring 时仍会替换 app。

支持的平台

平台	前缀
macOS arm64（Apple Silicon）	/opt/homebrew
Linux x86_64	/home/linuxbrew/.linuxbrew
Linux arm64	/home/linuxbrew/.linuxbrew

Intel Mac 不受支持——brew 管理器在那边报告自身不可用。这与 src/system/packages/brew/mod.rs 的 is_available() 一致：cfg!(all(target_os = "macos", target_arch = "aarch64")) 或 Linux x86_64/aarch64。Linux 上，若你的架构没有对应 bottle（homebrew/core 大多有 arm64 Linux bottle 但并非全部），则改为从源码构建。

前缀

若前缀不存在，mise 会以标准布局创建它。公式安装可能为前缀创建与所有权设置提权（mkdir + chown），之后以前缀所有者身份写公式。cask 安装也可能因包安装器或生命周期步骤需要提权。请以预期所有者身份运行 mise，让它按需为每一步请求权限。

链接的命令需要 <prefix>/bin 在 PATH 上。例如在合适的 shell 启动文件中：

# Apple Silicon macOS
export PATH="/opt/homebrew/bin:$PATH"

# Linux
# export PATH="/home/linuxbrew/.linuxbrew/bin:$PATH"

keg-only 公式不会链接到那里；给编译器或服务配置时请使用其 <prefix>/opt/<formula> 路径。

与真实 Homebrew 共存

mise 完全像 brew 一样把 bottle 灌入 Cellar，并在每个 keg 写入 brew 兼容的 INSTALL_RECEIPT.json（源码见 src/system/packages/brew/pour.rs，模块注释明确写 "mise never shells out to brew to pour a bottle; the receipts it writes are brew-compatible"）。对真实 Homebrew 而言，mise pouring 的 keg 看起来就是自己的：brew list、brew upgrade、brew uninstall 都能操作。反过来，mise 的 status 检查直接读 Cellar，所以 brew 安装的公式也计为已安装。

对非 keg-only 公式，mise 维护 Homebrew 的 <prefix>/var/homebrew/linked/<name> 记录及 opt 记录。对已配置公式，任一记录缺失时 mise bootstrap packages apply 会恢复它，而不重灌 keg 或替换其公开链接（对应 src/system/packages/brew/mod.rs 的 repair_records）。旧版 mise 安装仅在现有公开链接匹配 keg 布局时才被识别为已链接。不做依赖闭包迁移。

mise 直接读 Homebrew 前缀，无论公式是 mise 还是真实 Homebrew 灌的。它永不覆盖前缀中非它创建的文件——链接冲突会以冲突文件清单失败，而不是覆盖。

导入与清理（import / prune）

mise bootstrap packages import --manager brew 把已安装的 Homebrew 公式快照进 [bootstrap.packages]，精神上与 brew bundle dump 类似。它读取 Homebrew 前缀中活动的 opt 链接并写出：

[bootstrap.packages]
"brew:ffmpeg" = "latest"
"brew:postgresql@17" = "latest"

默认只记录活动 keg receipt 标记为 on-request 安装的公式；--all 可包含依赖公式。tap 公式写全限定名，且当 mise 能推断出约定俗成的 GitHub tap URL 时会自动加 [bootstrap.brew.taps] 条目（实现见 src/system/packages/brew/maintenance.rs，其中 installed_on_request 读自 INSTALL_RECEIPT.json 的 installed_on_request 字段）：

[bootstrap.brew.taps]
"acme/tools" = "https://github.com/acme/homebrew-tools.git"

[bootstrap.packages]
"brew:acme/tools/widget" = "latest"

mise bootstrap packages prune --manager brew 把当前配置与受信任、可加载的 tracked 配置视为事实来源，移除不在这些已配置 brew: 条目解析依赖闭包内的已链接 Homebrew 公式——包括真实 Homebrew 安装的公式。prune 移除活动 keg、其 opt 与 linked-keg 记录，以及指向该 keg 的前缀符号链接。--dry-run 预览，--yes 跳过确认。该命令是 mise 对 bootstrap 包的声明式清理（类比 brew bundle cleanup），不是上游 brew prune（Homebrew 已移除它，改用 cleanup 命令）。

mise bootstrap packages prune --manager brew-cask 对直接 cask 工件应用同样的合并配置模型，但所有权边界刻意更窄：只有 install 时的 .mise-cask.toml receipt 明确标记可安全清理、且每个记录目标仍保有安装后记录的精确内容指纹时，才移除 cask。命令移除这些目标与 cask 的 Caskroom 条目；--dry-run 预览、--yes 跳过确认。被收养与自更新应用没有重复 Caskroom bundle，mise 无法证明同一目标后来的 bundle 仍归它所有，因此这些仅元数据应用永不被 prune 移除。

receipt 早于 prune 元数据的 cask 会跳过，直到后续升级或重装刷新 receipt。带 pkg/command wrapper 工件、安装或卸载生命周期动作、待处理事务、Homebrew .metadata、目标变更，或与另一 mise cask 共享目标的 cask 也带原因跳过。Prune 从不运行 zap 元数据，也从不基于当前 Homebrew API 重构历史卸载行为。

pouring 工作原理

对依赖闭包中的每个公式（依赖优先），依次执行（流程对应 src/system/packages/brew/mod.rs 的 install_via_pour，与 src/system/packages/brew/pour.rs 的 "extract -> relocate -> codesign -> receipt -> link" 注释）：

1. Fetch：从 ghcr.io 为你的平台下载 bottle，对照 API 元数据校验 sha256；
2. Extract：解压进 Cellar 内的临时目录（未完成的 pour 永远不会作为已安装包可见）；
3. Relocate：bottle 内嵌 @@HOMEBREW_PREFIX@@ 之类的占位路径，mise 重写为真实路径——文本文件直接替换，二进制背书的可执行文件（如 zipapps）改写 shebang 前导（保持 payload 不动）；Mach-O 二进制做就地与 load-command 重写（必要时把 load commands 扩入头部 padding，与 brew 的 ruby-macho 一致）。Linux 上按 brew PatchELF gem 的方式修补 ELF interpreter 与 rpath：放不下的字符串移入追加到二进制末尾的新段，interpreter 指向 <prefix>/lib/ld.so（mise 维护的指向系统动态加载器的符号链接，安装了 brewed glibc 时指向它）——对应 src/system/packages/brew/relocate.rs、macho.rs、elf.rs；
4. Re-sign（macOS）：任何被修改的二进制用 codesign ad-hoc 重签——arm64 上是必需的，内核会杀掉签名不匹配的二进制；
5. Receipt：写入 brew 兼容的 INSTALL_RECEIPT.json；
6. Link：创建 <prefix>/opt/<name>，并把 keg 的 bin、lib、include、share 等符号链接进前缀（LINK_DIRS 常量见 src/system/packages/brew/pour.rs）；非 keg-only 公式创建 linked-keg 记录；keg-only 公式只拿 opt 链接，不链进前缀——与 brew 一致。

源码公式

少数公式完全没有 bottle（纯源码公式），有些只有别的平台有 bottle。mise 仍不借助 Homebrew 从源码构建：

1. Ruby：公式是 Ruby 代码，mise 通过常规工具机制供应 mise 管理的 ruby（预编译、快速；尊重你已配置的 ruby）——见 src/system/packages/brew/source.rs 的 ruby_bin()；
2. Formula：从 homebrew/core 下载公式 .rb，钉在 API 元数据生成时的精确 commit，并用 API 对该文件的 sha256 校验；
3. Source：下载 stable 源码归档，对照 API sha256 校验；
4. Build deps：公式的构建依赖（cmake、pkgconf 等）先加入安装闭包，作为常规 bottle pouring；
5. Build：mise 用自家 Formula-DSL shim（src/system/packages/brew/shim.rb）评估公式并针对规范前缀运行 def install，PATH、PKG_CONFIG_PATH 与编译器 flags 指向依赖 keg。keg 获得与 poured bottle 相同的 brew 兼容 receipt，poured_from_bottle: false——与 brew 标记自家源码构建完全一致。

shim 实现公式 DSL 的常用子集（configure/cmake/meson 风格构建、resources、patches、标准路径与环境助手）。使用 shim 未覆盖 DSL 部分的公式——virtualenv_install_with_resources 这类语言专用助手、VCS 下载等——会以清晰的 formula uses ... 错误失败，而不是静默错误编译。

源码构建需要可用的工具链（macOS 的 Xcode Command Line Tools、Linux 的 gcc/make），与在纯 Homebrew 下完全一样。

升级

mise bootstrap packages upgrade 对照 formulae.brew.sh API 重新解析已配置公式，pour 掉任何当前版本与已链接 keg 不同的公式——新 keg 替换旧 keg，链接重指，与 brew upgrade 的舞步相同。由于 bottle 只存在于公式的当前版本，"升级"与"安装当前 bottle"是同一操作。

故障排查

• 链接冲突：先检查 mise 列出的路径并确认所有者再改动。重复 apply 不授权覆盖无关文件。
• 不支持的公式 DSL 或 cask 工件：阅读指名的不受支持操作。mise 的内置安装器有自己的覆盖范围；上游 Homebrew 配方不保证受支持。
• 已安装但命令缺失：检查前缀的 bin 目录，确认公式是否 keg-only。
• 现有应用不同：决定是在 mise 之外继续管理它，还是用文档化的 adoption 流程。adopt 不是覆盖不同应用的许可。
• 应用替换成功但权限变了：检查该应用的 macOS 隐私与安全授权。

限制

• cask 工件覆盖刻意收窄：macOS 上 brew-cask 支持 app bundle、binary 工件、生成命令包装器、通用前缀工件、字体工件、简单 pkg 安装器、脚本安装器，以及来自 dmg 与常见归档格式的 shell 补全；Linux 上仅支持无生命周期钩子、无结构化 preflight_steps/postflight_steps 的纯字体 cask。其他工件类型、无 pkgutil ID 的 pkg 安装器、带自定义选项的 pkg 安装器会明确失败。
• brew services 未实现。
• cask import 未实现。cask prune 限于 mise 拥有的直接工件，且 install 时 receipt 证明可安全移除；pkg 工件与带生命周期动作的 cask 在卸载语义受支持前跳过。
• 源码构建覆盖常见公式形态：mise 的公式 shim 实现广泛使用的 DSL 子集（见上文 源码公式）；超出范围的公式以指名不受支持特性的清晰错误失败。
• 使用规范公式名：postgresql@17 是公式名而非 mise 版本 pin——API 的当前 stable 版本决定安装什么。别名（postgres）能正确安装，但 mise bootstrap packages status 无法追踪；mise 会警告并告知规范名。
• PATH 由你负责：<prefix>/bin 必须在 PATH 上才能使用链接的二进制，与 Homebrew 自身一样。

延伸阅读

• 包管理入口文档：docs/bootstrap.md 与 docs/bootstrap/packages/ 目录下的其他管理器说明；
• 命令实现：src/cli/bootstrap.rs、src/cli/system/import.rs、src/cli/system/prune.rs、src/cli/system/upgrade.rs；
• 核心模块：src/system/packages/brew/mod.rs、src/system/packages/brew/pour.rs、src/system/packages/brew/source.rs、src/system/packages/brew/maintenance.rs、src/system/packages/brew/cask/mod.rs、src/system/packages/brew/cask/tests.rs。