尧图网站建设 
如何用 uv 更新 MongoDB 仓库的 Python 依赖并同步 uv.lock【免费下载链接】mongoThe MongoDB Database项目地址: https://gitcode.com/GitHub_Trending/mo/mongoMongoDB 仓库用 uv、uv_sync.sh 和 uv_lock_check.py 的正文给出这条从改声明到验证锁文件一致的完整操作路径。适用前提来自 构建文档 与 pyproject.tomlPython 3.13pyproject.toml中requires-python 3.13,4.0已有一个 git 仓库检出命令都在仓库根目录执行uv 版本被仓库钉在 buildscripts/uv_version.txt 中的0.11.13uv_sync.sh会自动把该版本装进 venv不需要你单独安装。注意范围嵌套的buildscripts/bazel_rules_mongo/包仍使用 Poetry它有自己的pyproject.toml/poetry.lock不走下面的 uv 流程。先看清依赖管理的文件布局docs/uv_execution.md 用一张表定义了各文件的角色更新依赖前值得先对照文件作用pyproject.toml事实来源。依赖声明在[project.dependencies]和 PEP 735[dependency-groups]下uv 专属配置在[tool.uv.*]uv.lockpyproject.toml的锁定解析。由uv lock --static-urls生成rules_pycross 要求逐 wheel 的 URL跨平台靠 PEP 508 markersbazel/uv/defs.bzl兼容 shim把dependency(name, groupNone)映射到pypi//name与旧的rules_poetry调用点逐字兼容buildscripts/uv_sync.sh工作站/CI 引导脚本把钉住的 uv 装进当前 venv并执行uv sync --all-groups --no-install-projectbuildscripts/uv_version.txt钉住的 uv 版本与pyproject.toml中的 pin 保持同步当前为0.11.13buildscripts/uv_lock_check.py提交前检查uv.lock相对pyproject.toml过期时直接失败准备条件激活 Python venvuv_sync.sh默认拒绝在没有激活的虚拟环境时运行这是为了防止误装到系统 Python激活 venv 是最省事的做法。按 测试文档 的做法python3 -m venv python3-venv source python3-venv/bin/activate如果你不想手动建 venv也可以直接运行bash buildscripts/uv_sync.sh -f-f会跳过“必须已激活 venv”的检查脚本随后会在仓库根目录自举出标准的python3-venv并把 uv 装进去。副作用仅限仓库内的python3-venv目录和其中的 pip 安装不会碰系统解释器。第一步修改 pyproject.toml按 docs/uv_execution.md 的 “Edit a dependency” 流程先改声明常规依赖加在[project.dependencies]下例如现有的pymongo4.12.0、networkx按用途分组的依赖加在[dependency-groups]的对应组里当前仓库定义了aws、core、lint、evergreen、testing、platform、wrapper-hook等组。一个容易踩的边界[project.optional-dependencies]下的libdeps组是 opt-in 的不会被uv sync --all-groups安装要用它需要单独uv sync --extra libdeps或pip install .[libdeps]。另外[tool.uv]里package false因为本仓库是开发工具集而非可发布包所以同步时始终带--no-install-project。第二步刷新 uv.lock 并提交文档给出的工作流是修改pyproject.toml运行buildscripts/uv_sync.sh -f刷新uv.lock文档说明其使用--static-urls把pyproject.toml和uv.lock一起提交。这里要如实说明一处文档与脚本的口径差异uv_execution.md 声称uv_sync.sh -f会“刷新uv.lock使用--static-urls”但当前版本的 uv_sync.sh 实际执行的是uv sync --locked --all-groups --no-install-project——--locked遇到过期的uv.lock会直接报错而不是自动重写。脚本注释和 uv_lock_check.py 的错误信息对这种情况的官方处理方式是从仓库根目录显式运行uv lock然后把结果提交。--static-urls参数则是为了让 uv 把每个 wheel 的 URL 和 sha256 写进锁文件rules_pycross 的硬性要求rapidyaml、pykmip、cryptography等在 pyproject.toml 的[tool.uv.sources]中配置了 S3/GitHub 直连 URL 的包尤其依赖这一点。因此可执行的顺序是改完pyproject.toml后在仓库根目录运行uv lock --static-urls再提交两个文件git add pyproject.toml uv.lock git commituv lock需要可用的 uv 二进制。若环境中没有先跑一次bash buildscripts/uv_sync.sh激活 venv 后它会把buildscripts/uv_version.txt钉住的uv0.11.13通过 pip 装进 venv。验证确认 uv.lock 与 pyproject.toml 一致有两个层次的验证都与文档一致1. 锁文件一致性检查。uv_lock_check.py 是仓库的提交前检查激活 venv 后直接运行buildscripts/uv_lock_check.py它做两件事任一不满足都会以非零码退出运行uv lock --check若uv.lock相对pyproject.toml过期输出uv.lock is out of sync with pyproject.toml. Runuv lockfrom the repo root and commit the result.校验pyproject.toml中export组的uv0.11.13pin 与buildscripts/uv_version.txt一致不一致时提示以uv_version.txt为权威来源修正。全部通过时的输出是uv.lock is in sync with pyproject.toml.该脚本按PATH中的uv→ 仓库根的python3-venv/bin/uv→ Bazel runfiles 的顺序寻找 uv 二进制找不到时会提示先跑buildscripts/uv_sync.sh或用 pipx 安装 uv。你也可以单独用文档在 devcontainer 排障指南 中给出的等价检查uv lock --check2. 环境安装验证。确认锁文件能用后把依赖装进 venvsource python3-venv/bin/activate bash buildscripts/uv_sync.sh该脚本会设置UV_PROJECT_ENVIRONMENT指向当前 venvuv 对uv sync这类项目命令默认忽略$VIRTUAL_ENV不这样指认会在仓库根另建一个.venv然后执行uv sync --locked --all-groups --no-install-project。装完后按排障文档的建议核对 uv 版本uv --version # 应与 buildscripts/uv_version.txt 中的 pin 一致如果这里再次报uv.lock过期说明提交前漏了刷新步骤回到“第二步”重跑uv lock --static-urls。可选分支只安装部分依赖组完整开发环境是--all-groups但排障或 CI 场景下可以只装某个组。docs/uv_execution.md 给出的形式--active指向已激活的 venv不加--active也没设UV_PROJECT_ENVIRONMENT时uv 会装到仓库根的.venv--locked在锁文件过期时拒绝运行而不是重写uv sync --active --locked --all-groups # 全部组开发默认 uv sync --active --locked --only-group lint # 只装 lint 组 uv sync --active --locked --all-groups --no-group powercycle-incompatible # powercycle 远端引导场景powercycle-incompatible组里只有带python_version 3.13marker 的rapidyaml注释说明它在 powercycle 的 atlas 发行版上存在问题所以远端引导会显式排除它。Evergreen CI 的 venv_setup.sh 用的也是同一套--locked --all-groups --no-install-project参数。为什么必须保持 uv.lock 同步这不是普通的缓存文件MODULE.bazel通过 rules_pycross 的lock_import.import_uv扩展直接消费uv.locklock_file //:uv.lockrepo 名pypiwheel 解析成http_file目标、sdist 变成pycross_wheel_buildaction两者都用锁文件里固化的 URL 和哈希构建时不再访问 simple index。uv sync如果带着隐式重解析去改写uv.lockvenv 里的解析结果就会和 Bazel 的pypihub 静默漂移——这正是--locked把它变成硬错误的原因。所以改完pyproject.toml后pyproject.toml、uv.lock以及改了 uv pin 时的buildscripts/uv_version.txt与pyproject.toml中export组的uvX.Y.Z要一起提交并保持三处版本一致。限制与边界只有顶层 Python 依赖走 uvbuildscripts/bazel_rules_mongo/仍走自己的 Poetry 生命周期不在本文范围内。uv_sync.sh的-p path可以显式指定解释器但它会拒绝非 venv 的解释器uv sync会卸载不在uv.lock里的包绝不能用于系统 Python默认依次回退到$PYTHON3和python3。Windows 上的 Cygwin/Git-Bash 环境脚本已处理Scripts/python.exe布局与cygpath路径转换但行为与 Unix 一致的前提仍是 venv 或-f自举。部分包的 URL 源指向外部地址mdb-build-publicS3、GitHub 归档 tarball。pykmip用的是 GitHub 归档 tarball 的直接 URL注释明确指出若 GitHub 重新打包导致字节变化必须重跑uv lock刷新提交的哈希。【免费下载链接】mongoThe MongoDB Database项目地址: https://gitcode.com/GitHub_Trending/mo/mongo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 如何用 uv 更新 MongoDB 仓库的 Python 依赖并同步 uv.lock
如何用 uv 更新 MongoDB 仓库的 Python 依赖并同步 uv.lock【免费下载链接】mongoThe MongoDB Database项目地址: https://gitcode.com/GitHub_Trending/mo/mongoMongoDB 仓库用 uv、uv_sync.sh 和 uv_lock_check.py 的正文给出这条从改声明到验证锁文件一致的完整操作路径。适用前提来自 构建文档 与 pyproject.tomlPython 3.13pyproject.toml中requires-python 3.13,4.0已有一个 git 仓库检出命令都在仓库根目录执行uv 版本被仓库钉在 buildscripts/uv_version.txt 中的0.11.13uv_sync.sh会自动把该版本装进 venv不需要你单独安装。注意范围嵌套的buildscripts/bazel_rules_mongo/包仍使用 Poetry它有自己的pyproject.toml/poetry.lock不走下面的 uv 流程。先看清依赖管理的文件布局docs/uv_execution.md 用一张表定义了各文件的角色更新依赖前值得先对照文件作用pyproject.toml事实来源。依赖声明在[project.dependencies]和 PEP 735[dependency-groups]下uv 专属配置在[tool.uv.*]uv.lockpyproject.toml的锁定解析。由uv lock --static-urls生成rules_pycross 要求逐 wheel 的 URL跨平台靠 PEP 508 markersbazel/uv/defs.bzl兼容 shim把dependency(name, groupNone)映射到pypi//name与旧的rules_poetry调用点逐字兼容buildscripts/uv_sync.sh工作站/CI 引导脚本把钉住的 uv 装进当前 venv并执行uv sync --all-groups --no-install-projectbuildscripts/uv_version.txt钉住的 uv 版本与pyproject.toml中的 pin 保持同步当前为0.11.13buildscripts/uv_lock_check.py提交前检查uv.lock相对pyproject.toml过期时直接失败准备条件激活 Python venvuv_sync.sh默认拒绝在没有激活的虚拟环境时运行这是为了防止误装到系统 Python激活 venv 是最省事的做法。按 测试文档 的做法python3 -m venv python3-venv source python3-venv/bin/activate如果你不想手动建 venv也可以直接运行bash buildscripts/uv_sync.sh -f-f会跳过“必须已激活 venv”的检查脚本随后会在仓库根目录自举出标准的python3-venv并把 uv 装进去。副作用仅限仓库内的python3-venv目录和其中的 pip 安装不会碰系统解释器。第一步修改 pyproject.toml按 docs/uv_execution.md 的 “Edit a dependency” 流程先改声明常规依赖加在[project.dependencies]下例如现有的pymongo4.12.0、networkx按用途分组的依赖加在[dependency-groups]的对应组里当前仓库定义了aws、core、lint、evergreen、testing、platform、wrapper-hook等组。一个容易踩的边界[project.optional-dependencies]下的libdeps组是 opt-in 的不会被uv sync --all-groups安装要用它需要单独uv sync --extra libdeps或pip install .[libdeps]。另外[tool.uv]里package false因为本仓库是开发工具集而非可发布包所以同步时始终带--no-install-project。第二步刷新 uv.lock 并提交文档给出的工作流是修改pyproject.toml运行buildscripts/uv_sync.sh -f刷新uv.lock文档说明其使用--static-urls把pyproject.toml和uv.lock一起提交。这里要如实说明一处文档与脚本的口径差异uv_execution.md 声称uv_sync.sh -f会“刷新uv.lock使用--static-urls”但当前版本的 uv_sync.sh 实际执行的是uv sync --locked --all-groups --no-install-project——--locked遇到过期的uv.lock会直接报错而不是自动重写。脚本注释和 uv_lock_check.py 的错误信息对这种情况的官方处理方式是从仓库根目录显式运行uv lock然后把结果提交。--static-urls参数则是为了让 uv 把每个 wheel 的 URL 和 sha256 写进锁文件rules_pycross 的硬性要求rapidyaml、pykmip、cryptography等在 pyproject.toml 的[tool.uv.sources]中配置了 S3/GitHub 直连 URL 的包尤其依赖这一点。因此可执行的顺序是改完pyproject.toml后在仓库根目录运行uv lock --static-urls再提交两个文件git add pyproject.toml uv.lock git commituv lock需要可用的 uv 二进制。若环境中没有先跑一次bash buildscripts/uv_sync.sh激活 venv 后它会把buildscripts/uv_version.txt钉住的uv0.11.13通过 pip 装进 venv。验证确认 uv.lock 与 pyproject.toml 一致有两个层次的验证都与文档一致1. 锁文件一致性检查。uv_lock_check.py 是仓库的提交前检查激活 venv 后直接运行buildscripts/uv_lock_check.py它做两件事任一不满足都会以非零码退出运行uv lock --check若uv.lock相对pyproject.toml过期输出uv.lock is out of sync with pyproject.toml. Runuv lockfrom the repo root and commit the result.校验pyproject.toml中export组的uv0.11.13pin 与buildscripts/uv_version.txt一致不一致时提示以uv_version.txt为权威来源修正。全部通过时的输出是uv.lock is in sync with pyproject.toml.该脚本按PATH中的uv→ 仓库根的python3-venv/bin/uv→ Bazel runfiles 的顺序寻找 uv 二进制找不到时会提示先跑buildscripts/uv_sync.sh或用 pipx 安装 uv。你也可以单独用文档在 devcontainer 排障指南 中给出的等价检查uv lock --check2. 环境安装验证。确认锁文件能用后把依赖装进 venvsource python3-venv/bin/activate bash buildscripts/uv_sync.sh该脚本会设置UV_PROJECT_ENVIRONMENT指向当前 venvuv 对uv sync这类项目命令默认忽略$VIRTUAL_ENV不这样指认会在仓库根另建一个.venv然后执行uv sync --locked --all-groups --no-install-project。装完后按排障文档的建议核对 uv 版本uv --version # 应与 buildscripts/uv_version.txt 中的 pin 一致如果这里再次报uv.lock过期说明提交前漏了刷新步骤回到“第二步”重跑uv lock --static-urls。可选分支只安装部分依赖组完整开发环境是--all-groups但排障或 CI 场景下可以只装某个组。docs/uv_execution.md 给出的形式--active指向已激活的 venv不加--active也没设UV_PROJECT_ENVIRONMENT时uv 会装到仓库根的.venv--locked在锁文件过期时拒绝运行而不是重写uv sync --active --locked --all-groups # 全部组开发默认 uv sync --active --locked --only-group lint # 只装 lint 组 uv sync --active --locked --all-groups --no-group powercycle-incompatible # powercycle 远端引导场景powercycle-incompatible组里只有带python_version 3.13marker 的rapidyaml注释说明它在 powercycle 的 atlas 发行版上存在问题所以远端引导会显式排除它。Evergreen CI 的 venv_setup.sh 用的也是同一套--locked --all-groups --no-install-project参数。为什么必须保持 uv.lock 同步这不是普通的缓存文件MODULE.bazel通过 rules_pycross 的lock_import.import_uv扩展直接消费uv.locklock_file //:uv.lockrepo 名pypiwheel 解析成http_file目标、sdist 变成pycross_wheel_buildaction两者都用锁文件里固化的 URL 和哈希构建时不再访问 simple index。uv sync如果带着隐式重解析去改写uv.lockvenv 里的解析结果就会和 Bazel 的pypihub 静默漂移——这正是--locked把它变成硬错误的原因。所以改完pyproject.toml后pyproject.toml、uv.lock以及改了 uv pin 时的buildscripts/uv_version.txt与pyproject.toml中export组的uvX.Y.Z要一起提交并保持三处版本一致。限制与边界只有顶层 Python 依赖走 uvbuildscripts/bazel_rules_mongo/仍走自己的 Poetry 生命周期不在本文范围内。uv_sync.sh的-p path可以显式指定解释器但它会拒绝非 venv 的解释器uv sync会卸载不在uv.lock里的包绝不能用于系统 Python默认依次回退到$PYTHON3和python3。Windows 上的 Cygwin/Git-Bash 环境脚本已处理Scripts/python.exe布局与cygpath路径转换但行为与 Unix 一致的前提仍是 venv 或-f自举。部分包的 URL 源指向外部地址mdb-build-publicS3、GitHub 归档 tarball。pykmip用的是 GitHub 归档 tarball 的直接 URL注释明确指出若 GitHub 重新打包导致字节变化必须重跑uv lock刷新提交的哈希。【免费下载链接】mongoThe MongoDB Database项目地址: https://gitcode.com/GitHub_Trending/mo/mongo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考