几个主流的环境管理器（rustup、uv、nvm、fnm）已经在鸿蒙 PC 上可用

1 前言

在进行软件开发的过程中，开发者经常需要用到各种环境管理器来管理自己的开发环境：Rust 用 rustup，Python 用 uv，Node.js 用 nvm 或 fnm。这些环境管理器都没有官方适配鸿蒙，用户很难在鸿蒙 PC 上使用这些工具。

现在，这四款环境管理器已经全部收录进 Harmonybrew 并完成了鸿蒙适配。大部分适配工作由我本人完成。

本文介绍它们的使用方式以及适配原理。

2 使用方式

2.1 rustup

rustup 是 keg-only 安装（避免与 brew install rust 冲突），需要手动把它的 bin 目录加入 PATH：

sh 复制代码

brew install rustup
export PATH="$(brew --prefix rustup)/bin:$PATH"

建议把第二行写入 ~/.zshrc。之后即可正常使用：

sh 复制代码

rustup show          # 首次会自动下载 stable 工具链
cargo new hello && cd hello && cargo run
# Hello, world!

默认工具链为 stable，且默认走阿里云 Rust 镜像，国内网络友好。

2.2 uv

sh 复制代码

brew install uv

无需额外 PATH 配置。基本用法：

sh 复制代码

uv venv --python 3.12 .venv
uv pip install numpy

uv 安装解释器时默认从 python-build-standalone 获取，且默认已经换成淘宝镜像源，国内可直接下载。

pip 三方库的源没有默认换（国内大部分情况下都能访问通，只是速度可能会慢）。如果觉得慢，可以自己换源。最简单的方式是设置环境变量 UV_DEFAULT_INDEX，一劳永逸：

sh 复制代码

export UV_DEFAULT_INDEX="https://mirrors.aliyun.com/pypi/simple/"

建议把这行写入 ~/.zshrc。也可以只在单次命令里临时指定：

sh 复制代码

uv pip install --index-url https://mirrors.aliyun.com/pypi/simple/ numpy

需要注意，uv 下载的解释器内置 pip 被禁用（python -m pip 会报错），这是刻意为之，请统一使用 uv add 或 uv pip install。

2.3 nvm

sh 复制代码

brew install nvm

鸿蒙 PC 上官方 nodejs.org/dist 不发布鸿蒙二进制，需要按 caveats 提示指定第三方分发源，并加载 nvm：

sh 复制代码

export NVM_NODEJS_ORG_MIRROR="https://ohos-node.com/dist"
mkdir -p ~/.nvm
export NVM_DIR="$HOME/.nvm"
[ -s "$(brew --prefix nvm)/nvm.sh" ] && \. "$(brew --prefix nvm)/nvm.sh"

建议把上面几行写入 ~/.zshrc。之后即可安装、切换 Node.js 版本：

sh 复制代码

nvm install --lts
nvm ls
node --version

2.4 fnm

sh 复制代码

brew install fnm

与 nvm 一样需要指定第三方分发源，并按 caveats 配置 shell 环境：

sh 复制代码

export FNM_NODE_DIST_MIRROR="https://ohos-node.com/dist"
eval "$(fnm env)"

建议把上面两行写入 ~/.zshrc。之后即可使用：

sh 复制代码

fnm install --lts
fnm use lts-latest
node --version

3 源的策略

包管理器本身的适配并不复杂：让它们识别鸿蒙这个平台，再保证工具自身能在鸿蒙上编译通过即可。真正难搞的是"源"------这些工具下载的语言环境从哪来、能不能在鸿蒙上跑。四个工具用了三种不同的策略解决源的问题。

3.1 rustup：对接 Rust 官方源

Rust 官方社区已经官方发布鸿蒙版 rust 工具链（ohos host triple），只是没签名、依赖的 OpenSSL 版本高于系统内置的 3.0.9、SSL 证书路径也没指向系统可用的位置，下载下来不能直接使用。

Harmonybrew 提供的 rustup 会用 patchelf 等工具对这个工具链做后处理，处理签名问题、OpenSSL 依赖问题和 SSL 证书路径问题，因此在用户视角上可以做到开箱即用。

由于官方从 stable 1.93.0 起才开始发布 ohos host 工具链（更早的版本只有 rust-std 的 ohos target，用于交叉编译），因此本工具支持的 rust 工具链版本有局限：仅 nightly 与 stable ≥ 1.93.0。

3.2 uv：蹭 musl 生态

uv 把鸿蒙解析为 linux-musl 平台，因此无论是它下载的 Python 解释器，还是后续安装的三方库 wheel，用的都是 musl 生态现成的制品。musl 生态成熟、PyPI 上的 musllinux wheel 覆盖面广，这条路最省事。

代价是：这些 musl 制品并未真正进行过鸿蒙适配，部分功能可能会异常，这在预期之内。Harmonybrew 的 uv 还会在安装时对 wheel 中的 ELF 文件自动签名，否则 musl 二进制在鸿蒙上无法加载执行。

3.3 nvm、fnm：自建 Node.js 源

Node.js 官方 nodejs.org/dist 不发布鸿蒙二进制，但我们有 musl 生态可蹭------unofficial-builds 会发布 linux-arm64-musl 版本的 Node.js。

然而，我没选择 musl 这条路，原因有三个：

musl 版的 Node.js 依赖 libgcc_s.so.1，鸿蒙系统不自带这个库，Harmonybrew 里面也没有，下载下来不能开箱即用。
Node.js 官方已经在源码层面支持鸿蒙，自己用源码编出真正的鸿蒙版能更稳定。
Node.js 给鸿蒙分配了独立的平台标识（openharmony），这个标识在编译期硬编码固定下来。如果用 musl 版本的 Node.js，它上报的是 linux 平台，将无法拉取到真正做了鸿蒙适配的 npm 包。

基于以上原因，我选择自建源这条路线：我自建了一个源：ohos-node.com/dist，里面提供了真正的鸿蒙版 Node.js，Harmonybrew 在安装提示中引导用户将 nvm 与 fnm 指向这个源拉取。

待 nvm 官方支持鸿蒙后，这个源可直接服务于官方 nvm。nvm 官方仓库已经有正在开启的鸿蒙适配 PR：https://github.com/nvm-sh/nvm/pull/3898 。