尧图网站建设 
Flower 贡献者入门实战基于 uv 的开发者环境搭建与框架开发工具链全解析【免费下载链接】flowerFlower: A Friendly Federated AI Framework项目地址: https://gitcode.com/GitHub_Trending/flo/flower本文基于 Flower 官方贡献者入门文档contributor-tutorial-get-started-as-a-contributor.rst系统讲解 Flower 联邦学习框架贡献者的完整开发工作流如何准备系统依赖、用uv引导出框架开发环境、使用protoc.sh/format.sh/test.sh等便捷脚本完成 Protobuf 代码生成、代码格式化与全量质量检查以及如何构建发布包与 Sphinx 文档。读完本文你可以独立完成一次克隆仓库 → 环境引导 → 本地验证 → 构建产物的完整贡献循环。前置条件工具链要求与依赖管理策略官方文档明确了贡献开发环境的基础要求组件版本要求用途Python3.11 或更高框架开发与运行环境仓库引导脚本默认钉住3.11.14uv0.10.7 或更高依赖管理、构建与发布工作流pyenv可选多 Python 版本管理Flower 的依赖管理策略值得先讲清楚仓库使用pyproject.toml声明依赖并配置开发工具凡支持该格式的工具均纳入其中uv承担依赖管理、构建和发布的全部工作流。这一策略在源码中有直接印证仓库根部的 dev/bootstrap.sh 是环境引导入口其最后一行执行uv sync --python${version} --locked --all-extras --all-groups——即严格使用锁定文件lockfile安装依赖并拉取所有 extras 与所有依赖组保证开发环境在团队成员之间完全一致框架模块 framework/pyproject.toml 与 framework/uv.lock 则钉住flwr包自身的依赖集合。也就是说贡献者不需要手工pip install任何开发依赖一切由uv按锁文件复现。开发者机器准备系统级依赖安装macOS按文档指引需要安装 Homebrew并完成安装后的 PATH 配置动作安装xz用于安装不同 Python 版本与pandoc本地构建文档必需$ brew install xz pandocUbuntu 22.04 及以上确保系统更新到最新状态后安装编译与文档构建所需的基础库$ apt update $ apt install build-essential zlib1g-dev libssl-dev libsqlite3-dev \ libreadline-dev libbz2-dev libffi-dev liblzma-dev pandoc这些开发头文件包zlib、libssl、libsqlite3、libreadline、libbz2、libffi、liblzma是源码编译 C 扩展与构建 Python 解释器时的常见依赖文档将pandoc一并列出是因为 Flower 文档管线在编译 RST 内容时需要它。引导 Flower 开发环境完整流程分三步克隆仓库从 contributor-tutorial-get-started-as-a-contributor.rst 原文继承$ git clone gitgithub.com:flwrlabs/flower.git $ cd flower安装 uv按 uv 官方安装说明操作版本 ≥ 0.10.7。执行引导脚本$ ./dev/bootstrap.sh默认使用仓库钉住的 Python 版本创建framework/.venv也可以显式传入一个 Python 版本作为第一个参数$ ./dev/bootstrap.sh 3.11.14从 dev/bootstrap.sh 源码可以看到该脚本的实际动作链解析脚本所在目录定位仓库根目录与framework目录调用 dev/setup-envs.sh 设置开发环境变量调用 framework/dev/rm-caches.sh 清理旧缓存避免脏构建检查uv是否已安装未安装则报错退出并提示安装地址进入framework目录执行uv sync --pythonversion --locked --all-extras --all-groups完成依赖同步。脚本中版本默认值version${1:-3.11.14}与文档使用仓库钉住的 Python 版本的说法一致——这正是框架要求的 Python 3.11 具体落地的版本。便捷脚本详解编译 Protobuf、格式化与测试仓库的 dev/ 子目录集中了日常开发脚本。以下三个脚本是使用频率最高的。编译 ProtoBuf 定义framework/dev/protoc.sh$ ./framework/dev/protoc.shFlower 的跨语言通信协议由 framework/proto 下的.proto文件定义编译产物由 Python 代码消费。查看 framework/dev/protoc.sh 的实现其核心逻辑极为简洁先切换到framework目录再执行python -m devtool.protoc --project-dir .。即代码生成逻辑被封装在 dev/devtool/protoc.py 这个可测试的开发工具模块中配套还有 dev/devtool/protoc_test.py 测试而非散落在 shell 里——这意味着生成流程本身也纳入了单元测试覆盖。自动格式化代码framework/dev/format.sh$ ./framework/dev/format.shframework/dev/format.sh 是一个覆盖多语言、多文件类型的格式化编排器从源码可以看到它依次执行步骤命令作用对象TOML 格式化taplo fmt全部.toml受 framework/taplo.toml 配置约束版权头检查/修复python -m devtool.check_copyright、devtool.init_py_fixpy/flwr包导入排序python -m isort --skip py/flwr/proto pyPython 源码跳过 proto 生成目录Python 代码风格python -m black -q --exclude py/flwr/proto pyPython 源码Lint 自修复python -m ruff check --fix py/flwrflwr包Proto 格式化clang-format -ifind 管道proto/flwr/proto/*.protoE2E 格式化isortblacke2e目录Markdown / RSTmdformat --number、docstrfmtdocs/source文档数据库 Schema 图注入paracelsus inject ...flwr/supercore/state/schema/README.md等 SQLAlchemy 表结构图可以看到格式化并非跑一下 black这么简单它统一治理了 TOML、Python、Proto、Markdown、RST 和数据库 Schema 文档图且对py/flwr/proto这类生成目录做了显式排除。paracelsus inject一步尤其有意思——它从 SQLAlchemy 模型dev.get_schema_base:Base自动生成表关系图写回 schema 的 README保证文档里的 Schema 图与代码模型始终同步。运行 Linter 和测试framework/dev/test.sh$ ./framework/dev/test.shframework/dev/test.sh 是本地质量门禁它接受第一个参数RUN_FULL_TEST默认true并可被环境变量RUN_PYTEST默认true控制是否跑 pytest。其检查顺序从源码可归纳为五类Python 检查connector 注册表一致性python -m dev.generate_connector --check对应 framework/dev/generate_connector.py、clang-format --Werror --dry-run校验 proto 格式、isort --check-only、black --check、devtool.init_py_check、docsigdocstring 签名一致性、ruff check、mypy、pylint单元测试python -m pytest --covpy/flwr带覆盖率运行脚本特意设置RAY_ENABLE_UV_RUN_RUNTIME_ENV0注释说明这是为了避免 Ray 的 uv runtime-env 钩子在uv run下 pytest 时卡住——这是一个非常实用的坑位记录Markdown / TOML / rST 检查mdformat --check、taplo fmt --check、docstrfmt --check后两者在RUN_FULL_TESTfalse时部分跳过SQLAlchemy Schema 检查用paracelsus inject ... --check校验 format.sh 中生成的 Schema 图是否为最新许可证检查devtool.check_copyright版权头检查以及licensecheck --fail-licenses gpl --zero确保依赖中不含 GPL 类许可证。RUN_FULL_TEST开关的设计让贡献者在开发中可以先跑轻量检查例如./framework/dev/test.sh false提交前再跑全量。集成 pre-commit 钩子文档推荐用 pre-commit 库把上述两个脚本纳入提交流程。钩子配置为执行./framework/dev/format.sh与./framework/dev/test.sh两项主要操作有两种使用方式永久安装钩子$ pre-commit install之后每次git commit都会触发格式化与 lint/test 流程赶时间时可用--no-verify绕过$ git commit --no-verify -m Add new feature一次性全量检查不改变git commit的默认行为$ pre-commit run --all-files对所有文件执行格式化和 lint/test 检查。在本地运行 GitHub ActionsCI借助Act工具可以把 GitHub Actions 工作流在本地容器环境中完整跑一遍按 Act 的安装说明装好后在 Flower 主仓库根目录执行$ actFlower 的默认工作流会在其下自动拉起所需的 Docker 容器环境。这为本地复现 CI 失败提供了标准手段——当远端流水线报红时贡献者可以先用act在本地重放同一工作流定位问题。构建发布Build ReleaseFlower 用uv构建发布产物官方文档将其封装为简单脚本$ ./framework/dev/build.sh构建得到的.whl与.tar.gz会存放在./framework/dist子目录。发布侧还有配套脚本 framework/dev/publish-nightly.sh 与 framework/dev/test-wheel.sh分别用于 nightly 发布与 wheel 产物验证可结合 framework/dev/ 目录进一步查阅。构建文档Sphinx 文档管线Flower 文档基于 Sphinx。在仓库框架目录的 framework/docs/Makefile 中可以看到完整的文档目标定义docs目标sphinx-build -D languageen -A langTrue source build/html/生成 HTML 文档先清理旧的build/htmlserve目标构建后用python -m http.server在本地起静态服务预览checklinks目标sphinx-build -b linkcheck校验文档中所有外链有效性报告输出至build/linkcheckupdate-text/update-lang目标通过sphinx-gettext与sphinx-intl管理 framework/docs/locales 下的多语言翻译。官方文档给出的本地构建命令是$ ./framework/dev/build-docs.sh它会生成 HTML 文档按文档说明位于./framework/doc/build/html从 Makefile 的BUILDDIR build与SOURCEDIR source结构看实际产物在framework/docs/build/html下的build/html目录。本地构建文档需要系统已安装 Pandoc——这也是为什么前面的 macOS / Ubuntu 依赖安装清单里都包含了pandoc。文档源文件本身位于 framework/docs/source其中包含 130 余个 RST 页面与大量架构图/示例图贡献者修改文档时应遵循test.sh中的docstrfmt/mdformat格式门禁。小结一次完整贡献循环把官方文档的主线串起来一位 Flower 贡献者的标准工作循环是安装系统依赖macOSbrew install xz pandocUbuntuapt install build-essential ... pandocgit clone仓库并安装uv≥ 0.10.7./dev/bootstrap.sh [3.11.14]引导framework/.venv开发环境开发中随时用./framework/dev/protoc.sh协议变更后、./framework/dev/format.sh、./framework/dev/test.sh维护代码质量推荐叠加 pre-commit 钩子用act本地复放 CI用./framework/dev/build.sh产出framework/dist下的发布包用./framework/dev/build-docs.sh验证文档构建。整套工具链的设计特点是以uv lockfile 保证环境可复现把多语言/多格式的质量门禁集中进三个入口脚本format/test/protoc并通过 dev/devtool 下的可测试 Python 模块如protoc.py、check_copyright.py、init_py_check.py把原本脆弱的 shell 逻辑变成有单元测试保障的开发者工具。新贡献者只要按上述路径走一遍即可与仓库的 CI 门禁对齐独立开展 Flower 框架的开发与贡献工作。【免费下载链接】flowerFlower: A Friendly Federated AI Framework项目地址: https://gitcode.com/GitHub_Trending/flo/flower创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Flower 贡献者入门实战：基于 uv 的开发者环境搭建与框架开发工具链全解析
Flower 贡献者入门实战基于 uv 的开发者环境搭建与框架开发工具链全解析【免费下载链接】flowerFlower: A Friendly Federated AI Framework项目地址: https://gitcode.com/GitHub_Trending/flo/flower本文基于 Flower 官方贡献者入门文档contributor-tutorial-get-started-as-a-contributor.rst系统讲解 Flower 联邦学习框架贡献者的完整开发工作流如何准备系统依赖、用uv引导出框架开发环境、使用protoc.sh/format.sh/test.sh等便捷脚本完成 Protobuf 代码生成、代码格式化与全量质量检查以及如何构建发布包与 Sphinx 文档。读完本文你可以独立完成一次克隆仓库 → 环境引导 → 本地验证 → 构建产物的完整贡献循环。前置条件工具链要求与依赖管理策略官方文档明确了贡献开发环境的基础要求组件版本要求用途Python3.11 或更高框架开发与运行环境仓库引导脚本默认钉住3.11.14uv0.10.7 或更高依赖管理、构建与发布工作流pyenv可选多 Python 版本管理Flower 的依赖管理策略值得先讲清楚仓库使用pyproject.toml声明依赖并配置开发工具凡支持该格式的工具均纳入其中uv承担依赖管理、构建和发布的全部工作流。这一策略在源码中有直接印证仓库根部的 dev/bootstrap.sh 是环境引导入口其最后一行执行uv sync --python${version} --locked --all-extras --all-groups——即严格使用锁定文件lockfile安装依赖并拉取所有 extras 与所有依赖组保证开发环境在团队成员之间完全一致框架模块 framework/pyproject.toml 与 framework/uv.lock 则钉住flwr包自身的依赖集合。也就是说贡献者不需要手工pip install任何开发依赖一切由uv按锁文件复现。开发者机器准备系统级依赖安装macOS按文档指引需要安装 Homebrew并完成安装后的 PATH 配置动作安装xz用于安装不同 Python 版本与pandoc本地构建文档必需$ brew install xz pandocUbuntu 22.04 及以上确保系统更新到最新状态后安装编译与文档构建所需的基础库$ apt update $ apt install build-essential zlib1g-dev libssl-dev libsqlite3-dev \ libreadline-dev libbz2-dev libffi-dev liblzma-dev pandoc这些开发头文件包zlib、libssl、libsqlite3、libreadline、libbz2、libffi、liblzma是源码编译 C 扩展与构建 Python 解释器时的常见依赖文档将pandoc一并列出是因为 Flower 文档管线在编译 RST 内容时需要它。引导 Flower 开发环境完整流程分三步克隆仓库从 contributor-tutorial-get-started-as-a-contributor.rst 原文继承$ git clone gitgithub.com:flwrlabs/flower.git $ cd flower安装 uv按 uv 官方安装说明操作版本 ≥ 0.10.7。执行引导脚本$ ./dev/bootstrap.sh默认使用仓库钉住的 Python 版本创建framework/.venv也可以显式传入一个 Python 版本作为第一个参数$ ./dev/bootstrap.sh 3.11.14从 dev/bootstrap.sh 源码可以看到该脚本的实际动作链解析脚本所在目录定位仓库根目录与framework目录调用 dev/setup-envs.sh 设置开发环境变量调用 framework/dev/rm-caches.sh 清理旧缓存避免脏构建检查uv是否已安装未安装则报错退出并提示安装地址进入framework目录执行uv sync --pythonversion --locked --all-extras --all-groups完成依赖同步。脚本中版本默认值version${1:-3.11.14}与文档使用仓库钉住的 Python 版本的说法一致——这正是框架要求的 Python 3.11 具体落地的版本。便捷脚本详解编译 Protobuf、格式化与测试仓库的 dev/ 子目录集中了日常开发脚本。以下三个脚本是使用频率最高的。编译 ProtoBuf 定义framework/dev/protoc.sh$ ./framework/dev/protoc.shFlower 的跨语言通信协议由 framework/proto 下的.proto文件定义编译产物由 Python 代码消费。查看 framework/dev/protoc.sh 的实现其核心逻辑极为简洁先切换到framework目录再执行python -m devtool.protoc --project-dir .。即代码生成逻辑被封装在 dev/devtool/protoc.py 这个可测试的开发工具模块中配套还有 dev/devtool/protoc_test.py 测试而非散落在 shell 里——这意味着生成流程本身也纳入了单元测试覆盖。自动格式化代码framework/dev/format.sh$ ./framework/dev/format.shframework/dev/format.sh 是一个覆盖多语言、多文件类型的格式化编排器从源码可以看到它依次执行步骤命令作用对象TOML 格式化taplo fmt全部.toml受 framework/taplo.toml 配置约束版权头检查/修复python -m devtool.check_copyright、devtool.init_py_fixpy/flwr包导入排序python -m isort --skip py/flwr/proto pyPython 源码跳过 proto 生成目录Python 代码风格python -m black -q --exclude py/flwr/proto pyPython 源码Lint 自修复python -m ruff check --fix py/flwrflwr包Proto 格式化clang-format -ifind 管道proto/flwr/proto/*.protoE2E 格式化isortblacke2e目录Markdown / RSTmdformat --number、docstrfmtdocs/source文档数据库 Schema 图注入paracelsus inject ...flwr/supercore/state/schema/README.md等 SQLAlchemy 表结构图可以看到格式化并非跑一下 black这么简单它统一治理了 TOML、Python、Proto、Markdown、RST 和数据库 Schema 文档图且对py/flwr/proto这类生成目录做了显式排除。paracelsus inject一步尤其有意思——它从 SQLAlchemy 模型dev.get_schema_base:Base自动生成表关系图写回 schema 的 README保证文档里的 Schema 图与代码模型始终同步。运行 Linter 和测试framework/dev/test.sh$ ./framework/dev/test.shframework/dev/test.sh 是本地质量门禁它接受第一个参数RUN_FULL_TEST默认true并可被环境变量RUN_PYTEST默认true控制是否跑 pytest。其检查顺序从源码可归纳为五类Python 检查connector 注册表一致性python -m dev.generate_connector --check对应 framework/dev/generate_connector.py、clang-format --Werror --dry-run校验 proto 格式、isort --check-only、black --check、devtool.init_py_check、docsigdocstring 签名一致性、ruff check、mypy、pylint单元测试python -m pytest --covpy/flwr带覆盖率运行脚本特意设置RAY_ENABLE_UV_RUN_RUNTIME_ENV0注释说明这是为了避免 Ray 的 uv runtime-env 钩子在uv run下 pytest 时卡住——这是一个非常实用的坑位记录Markdown / TOML / rST 检查mdformat --check、taplo fmt --check、docstrfmt --check后两者在RUN_FULL_TESTfalse时部分跳过SQLAlchemy Schema 检查用paracelsus inject ... --check校验 format.sh 中生成的 Schema 图是否为最新许可证检查devtool.check_copyright版权头检查以及licensecheck --fail-licenses gpl --zero确保依赖中不含 GPL 类许可证。RUN_FULL_TEST开关的设计让贡献者在开发中可以先跑轻量检查例如./framework/dev/test.sh false提交前再跑全量。集成 pre-commit 钩子文档推荐用 pre-commit 库把上述两个脚本纳入提交流程。钩子配置为执行./framework/dev/format.sh与./framework/dev/test.sh两项主要操作有两种使用方式永久安装钩子$ pre-commit install之后每次git commit都会触发格式化与 lint/test 流程赶时间时可用--no-verify绕过$ git commit --no-verify -m Add new feature一次性全量检查不改变git commit的默认行为$ pre-commit run --all-files对所有文件执行格式化和 lint/test 检查。在本地运行 GitHub ActionsCI借助Act工具可以把 GitHub Actions 工作流在本地容器环境中完整跑一遍按 Act 的安装说明装好后在 Flower 主仓库根目录执行$ actFlower 的默认工作流会在其下自动拉起所需的 Docker 容器环境。这为本地复现 CI 失败提供了标准手段——当远端流水线报红时贡献者可以先用act在本地重放同一工作流定位问题。构建发布Build ReleaseFlower 用uv构建发布产物官方文档将其封装为简单脚本$ ./framework/dev/build.sh构建得到的.whl与.tar.gz会存放在./framework/dist子目录。发布侧还有配套脚本 framework/dev/publish-nightly.sh 与 framework/dev/test-wheel.sh分别用于 nightly 发布与 wheel 产物验证可结合 framework/dev/ 目录进一步查阅。构建文档Sphinx 文档管线Flower 文档基于 Sphinx。在仓库框架目录的 framework/docs/Makefile 中可以看到完整的文档目标定义docs目标sphinx-build -D languageen -A langTrue source build/html/生成 HTML 文档先清理旧的build/htmlserve目标构建后用python -m http.server在本地起静态服务预览checklinks目标sphinx-build -b linkcheck校验文档中所有外链有效性报告输出至build/linkcheckupdate-text/update-lang目标通过sphinx-gettext与sphinx-intl管理 framework/docs/locales 下的多语言翻译。官方文档给出的本地构建命令是$ ./framework/dev/build-docs.sh它会生成 HTML 文档按文档说明位于./framework/doc/build/html从 Makefile 的BUILDDIR build与SOURCEDIR source结构看实际产物在framework/docs/build/html下的build/html目录。本地构建文档需要系统已安装 Pandoc——这也是为什么前面的 macOS / Ubuntu 依赖安装清单里都包含了pandoc。文档源文件本身位于 framework/docs/source其中包含 130 余个 RST 页面与大量架构图/示例图贡献者修改文档时应遵循test.sh中的docstrfmt/mdformat格式门禁。小结一次完整贡献循环把官方文档的主线串起来一位 Flower 贡献者的标准工作循环是安装系统依赖macOSbrew install xz pandocUbuntuapt install build-essential ... pandocgit clone仓库并安装uv≥ 0.10.7./dev/bootstrap.sh [3.11.14]引导framework/.venv开发环境开发中随时用./framework/dev/protoc.sh协议变更后、./framework/dev/format.sh、./framework/dev/test.sh维护代码质量推荐叠加 pre-commit 钩子用act本地复放 CI用./framework/dev/build.sh产出framework/dist下的发布包用./framework/dev/build-docs.sh验证文档构建。整套工具链的设计特点是以uv lockfile 保证环境可复现把多语言/多格式的质量门禁集中进三个入口脚本format/test/protoc并通过 dev/devtool 下的可测试 Python 模块如protoc.py、check_copyright.py、init_py_check.py把原本脆弱的 shell 逻辑变成有单元测试保障的开发者工具。新贡献者只要按上述路径走一遍即可与仓库的 CI 门禁对齐独立开展 Flower 框架的开发与贡献工作。【免费下载链接】flowerFlower: A Friendly Federated AI Framework项目地址: https://gitcode.com/GitHub_Trending/flo/flower创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考