Composio Python SDK 发布工作流构建、版本提升与客户端依赖锁定【免费下载链接】composioComposio powers 1000 toolkits, tool search, context management, authentication, and a sandboxed workbench to help you build AI agents that turn intent into action.项目地址: https://gitcode.com/GitHub_Trending/co/composio导读本文围绕 Composio 仓库中 Python SDK 的发布流程展开完整梳理从「构建产物」到「composio-client 版本锁定」再到「发布前验证」的完整链路。你将掌握make build的多包构建机制、bump.py的语义化版本提升交互、跨pyproject.toml/setup.py/uv.lock三处同步的客户端依赖更新方法以及发布前的 import 与 nox 检查清单。所有命令均以当前仓库python/目录的真实实现为依据可直接用于实际发布操作。一、发布工作流总览Composio 的 Python 侧发布流程在仓库中被抽象为「构建 → 版本提升 → 依赖锁定 → 验证」四个环节其权威操作说明记录在 .agents/skills/python-release/references/release-workflow.md配套的技能入口 .agents/skills/python-release/SKILL.md 明确要求在修改 Python 发布元数据或生成的客户端版本锁定之前必须先阅读该引用文档。此外python/docs/release.md 给出了从高层视角的发布步骤确定要发布的包 → 运行python scripts/bump.py→ 按提示选择版本类型或跳过 → 创建发布 PR → 合并并发布 GitHub Release。它同时强调两条注意事项开发活跃在next分支时创建 GitHub Release 只能选择该分支开发期间发布版本时应选择pre以生成 release-candidate 版本。二、构建make build的多包产物收集2.1 命令入口与前置条件在环境就绪后从python/目录执行make build对应实现位于 python/Makefilebuild: clean-build ./.venv/bin/python -m build set -e; for provider in $(PROVIDER_DIRS); do\ ./.venv/bin/python -m build $$provider;\ cp $$provider/dist/* dist/;\ done2.2 三个阶段拆解make build实际做三件事先执行clean-build清空dist/、build/以及所有 provider 包各自的dist/、build/产物见 python/Makefile保证每次构建从干净状态开始避免陈旧产物混入发布。构建根包通过./.venv/bin/python -m build构建根目录的composio主包对应 python/pyproject.toml 中的[project]元数据。逐个构建 provider 包并收集产物PROVIDER_DIRS由 Makefile 动态推导扫描providers/*/pyproject.toml对每个 provider 执行python -m build后将其dist/下的产物统一cp到根dist/。这样最终dist/中会汇聚根包与全部 provider 包的发行文件便于统一上传。从仓库现状看python/providers/下存在 anthropic、autogen、claude_agent_sdk、crewai、gemini、google、google_adk、langchain、langgraph、llamaindex、openai、openai_agents 共 12 个 provider 包每个都带有独立的pyproject.toml例如 python/providers/openai/pyproject.toml构建时会被一并收集。三、版本提升bump.py与make bump3.1 两种入口完整发布流程python scripts/bump.py对应 python/docs/release.md 的步骤 2便捷封装make bump其定义为bump: clean-builduv run python scripts/bump.py见 python/Makefile即先清理构建产物再执行版本提升。3.2 交互式版本选择bump.py 基于 click 与 semver 实现脚本会扫描当前目录下所有pyproject.toml与setup.py跳过.venv、venv、.nox、.tox、temp、node_modules、site-packages等目录对每个包逐一提示版本提升类型选择键类型对应 semver 操作Mmajornext_version(major)mminornext_version(minor)ppatchnext_version(patch)cprenext_version(prerelease)用于 release-candidatebpostbump_build(tokenpost)sskip跳过该包脚本对-分隔的预发布标记如rc后缀做了专门处理先剥离再解析支持对已有 RC 版本继续提升。同时提供了--pre/--post/--patch/--minor/--major五个命令行选项见 bump.py可绕过交互提示直接指定提升类型适合自动化流水线。3.3 两种元数据文件的修改方式pyproject.toml读取[project].name与[project].version用新版本替换version ...bump.pysetup.py解析setup(...)参数中的name与version替换version...bump.py。注意名为composio的主setup.py会被跳过因为其版本由 pyproject.toml 主导bump.py。当前仓库的根版本为0.21.1可见于 python/pyproject.tomlprovider 包与根包保持同版本如 python/providers/openai/pyproject.toml。四、Client Pin Bumpscomposio-client版本锁定Composio SDK 的架构分为两层上层的composio核心包以及下层的composio-client负责与 Composio 平台 API 通信的客户端。发布composio时通常需要同步更新其对composio-client的精确版本锁定pin。4.1 先验证目标版本可解析在提升composio-client锁定之前必须先确认新版本已发布到 PyPI 且能被解析pip index versions composio-client这一前置校验能避免把尚不存在的版本写入依赖声明。4.2 三处锁定文件必须同步更新composio-client的锁定散落在三处更新时必须一起修改保持完全一致文件当前锁定python/pyproject.tomlcomposio-client1.43.0python/setup.pycomposio-client1.43.0根目录 uv.lockcomposio-client版本1.43.0含 hash 校验与 sdist/wheel 记录从 uv.lock 的锁定条目可以看到composio-client 1.43.0同时记录了 sdist 与py3-none-anywheel 的下载地址与 sha256 哈希锁文件与元数据声明必须一致否则uv sync会检测到漂移。4.3 重新生成锁文件三处文件更新完成后在仓库根目录执行uv lock --upgrade-package composio-client--upgrade-package仅针对composio-client这一个包重新解析并升级而不会动其他依赖的锁定从而把变更面控制在最小范围。执行完成后应检查 uv.lock 中的composio-client条目版本号已随之更新。4.4 为什么是精确锁定观察 python/pyproject.toml 的依赖声明可以发现一个规律平台相关的基础依赖pysher、pydantic、openai、jsonschema 等大多使用的下限约束而composio-client使用精确锁定。这是因为客户端与平台 API 的契约耦合紧密SDK 发布时必须以确定性版本与平台端行为对齐避免下游用户解析到不兼容的客户端版本。setup.py中的 install_requires 与 pyproject.toml 保持一致这也是「两处必须同步」的根本原因。五、发布前验证import 检查与 nox/Makefile 检查5.1 快速 import 冒烟检查依赖变更后第一步是验证包能正常导入、依赖解析无误uv run --package composio python -c import composio--package composio确保以composio包的工作区上下文运行从而按锁定的依赖集解析。这一步能最快暴露依赖缺失、版本冲突或元数据错误例如composio-client锁定版本在锁文件中不同步导致的解析失败。5.2 运行与本次变更相关的 nox/Makefile 检查导入检查通过后运行与本次变更相关的聚焦检查。当前仓库的检查面定义在 python/noxfile.py常用会话包括会话内容对应 Makefile 别名chkruff 静态检查 mypy 类型检查覆盖composio/、providers/、tests/、scripts/make chk/make checktst安装核心包与 crewai/langchain/langgraph provider 后运行 pytest 全量测试make tst/make testsnt快速冒烟tests/test_imports.py与tests/test_sdk.pymake snt/make sanitytype_inference安装全部 12 个 provider 包后对类型推断测试文件跑 mypymake type_inferencedead_codevulture 死代码报告仅报告不阻塞make dead-code例如若本次变更仅涉及依赖锁定优先跑make sntimport 与 SDK 初始化冒烟即可快速获得信心若同时改了 SDK 行为则应跑make tst全量测试。各 Makefile 别名定义见 python/Makefile。值得留意的是 noxfile.py 的依赖治理设计类型桩与 provider 库types-requests、crewai、langchain、llama-index 等没有放进pyproject.toml的dev依赖组而是由 nox 会话按需session.install原因在文件注释中写得很清楚——provider 库会拖入冲突的传递依赖破坏根包的解析稳定性。这种「锁文件只保留真正需要的依赖」的思路同样适用于发布流程验证环境与发布产物应当尽量贴近最终用户的可解析环境。六、发布流程的完整执行顺序综合 .agents/skills/python-release/references/release-workflow.md、python/docs/release.md 与源码实现一次典型的 Python SDK 发布按以下顺序执行准备环境在python/下准备好虚拟环境可用make env创建见 python/Makefile确认要发布的包决定根包与哪些 provider 包进入本次发布提升版本make bump或python scripts/bump.py按提示为每个包选择 major/minor/patch/pre/post 或跳过开发期间选择pre生成 RC 版本如涉及更新 client pinpip index versions composio-client确认版本 → 同步修改 python/pyproject.toml、python/setup.py 与根 uv.lock → 在根目录执行uv lock --upgrade-package composio-client构建在python/下执行make build产出并收集所有发行包到dist/验证uv run --package composio python -c import composio再运行与变更相关的 nox/Makefile 检查make snt/make chk/make tst等创建发布 PR 并合并提交版本与锁定变更创建发布 PR合并后在next分支上创建 GitHub Release 完成发布。通过这套「构建—提升—锁定—验证」的流程闭环可以确保每个发布的 SDK 版本都带着正确的版本号、与平台端对齐的客户端锁定以及通过验证的构建产物。【免费下载链接】composioComposio powers 1000 toolkits, tool search, context management, authentication, and a sandboxed workbench to help you build AI agents that turn intent into action.项目地址: https://gitcode.com/GitHub_Trending/co/composio创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考