公司动态

uv self update 实战指南:升级、降版本、团队对齐,3 条命令搞定

📅 2026/8/29 9:49:28
uv self update 实战指南:升级、降版本、团队对齐,3 条命令搞定
uv self update 实战指南升级、降版本、团队对齐3 条命令搞定【免费下载链接】uvAn extremely fast Python package and project manager, written in Rust.项目地址: https://gitcode.com/GitHub_Trending/uv/uv$ uv self update error: Self-update is only available for uv binaries installed via the standalone installation scripts.如果你刚用pip install uv装好 uv然后兴冲冲跑uv self update大概率会撞上上面这句报错。uvAstral 用 Rust 写的 Python 包管理器的自更新只有一条命令但版本升级这件事里一半的坑都在你的 uv 是怎么装上的。这篇按真实场景讲第一次升级报错怎么解、怎么装回旧版本、团队里 uv 版本不一致怎么办、升级翻车怎么救回来。第一次升级报错先确认 uv 的安装方式uv self update只认**独立安装脚本standalone installer**装出来的 uv。判断依据是一个收据文件uv 装的时候会写一份uv-receipt.json默认在~/.config/uv/uv-receipt.json自更新时先读它。没有收据直接报上面那句错并提示你用pip install --upgrade、brew upgrade之类的方式升级。所以第一步永远是看你的 uv 到底是谁装的which uv uv --version~/.local/bin/uv或~/.cargo/bin/uv——独立脚本装的可以继续用uv self update~/venvs/.../bin/uv或 pip 装的路径——自更新不可用用pip install --upgrade uvHomebrew 装的——brew upgrade uv还有一种更隐蔽的情况机器上有两份 uvPATH 里排在前面的那份不是独立脚本装的。此时报错会直接告诉你两个路径error: The current executable is at /usr/local/bin/uv but the standalone installer was used to install uv to /home/you/.local/bin/uv. Are multiple copies of uv installed?用which -a uv把所有 uv 找出来把顺序理顺问题就解决了一半。一条命令完成升级确认安装方式没问题后uv 如何升级到最新版本就很简单了uv self update它做的事情读当前版本 → 查最新 release → 下载对应平台的uv-installer.sh或 Windows 下的uv-installer.ps1→ 重新执行一遍安装脚本装回原来的目录缓存和配置都不动。输出大概是info: Checking for updates... success: Upgraded uv from v0.9.4 to v0.9.14!升级会重跑安装脚本理论上可能再改一次 shell 配置不想让它动加一个环境变量UV_NO_MODIFY_PATH1 uv self update另外两个参数值得记住# 只看有没有新版本不动手 uv self update --dry-run # GitHub API 限流403时带上 token uv self update --token ghp_xxx # 或设 UV_GITHUB_TOKEN--dry-run的输出是Would update uv from v0.9.4 to v0.9.14CI 里先 dry-run 再决定要不要真升级是个稳妥的习惯。安装指定版本与降版本很多人不知道的是uv self update后面可以直接跟一个精确版本号而且可以用来降级。uv self update 0.10.4 # 升级到 0.10.4 uv self update 0.6.0 # 降回 0.6.0输出会显示 Downgraded uv from ... to ...两个细节容易踩坑版本号必须写成完整的主.次.补丁三段比如0.10.4。传0.10或v0.10.4会被直接拒绝报错提示 explicit versions must include an exact major.minor.patch release。没有--patch、--minor、--rollback这类模糊参数想回到旧版本就老老实实写死版本号。所以回滚这件事 uv 没有单独做命令降版本就是它本身。团队里 uv 版本不一致怎么办场景很常见你上周升级到了 0.10同事还停在 0.8同一个uv.lock解析出不一样的结果互相怀疑对方依赖写错了。uv 本身没有强制最低版本这样的开关对齐版本得靠约定加固定版本安装成本其实很低项目文档里写死当前使用的 uv 版本号比如0.10.4新人入职照着装需要统一时让所有人跑同一条命令uv self update 0.10.4装的是完全一样的二进制CI 里最干净每次都用独立脚本装指定版本而不是依赖 runner 上残留的 uv。配合uv --version写进 CI 的第一步做检查版本一旦漂移pipeline 第一行就会红比等人发现快得多。升级失败怎么排查和救回来按报错对号入座error: Self-update is not possible because network connectivity is disabled你带了--offline自更新依赖网络去掉即可。error: GitHub API rate limit exceeded. Please provide a GitHub token via the --token option.共享 IP 触发了限流加--token或设UV_GITHUB_TOKEN。error: The current executable is at ... but ... Are multiple copies of uv installed?机器上有多份 uv回到第一节的which -a uv处理。升级装坏了怎么救顺序很简单新 uv 二进制还在能跑的uv self update 0.6.0直接降回去二进制本身起不来了删掉它重新跑一遍独立安装脚本装回任意版本——收据文件还在~/.config/uv/装完uv self update依然可用。最后一句提醒用UV_UNMANAGED_INSTALL装的无人管理模式常见于 CI会主动关闭自更新这是设计如此别在这上面浪费排查时间。现在就打开终端跑一条uv self update --dry-run看看你的 uv 离最新版本差几轮。【免费下载链接】uvAn extremely fast Python package and project manager, written in Rust.项目地址: https://gitcode.com/GitHub_Trending/uv/uv创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考