后端【免费下载链接】google-api-python-client The official Python client library for Googles discovery based APIs.项目地址https://gitcode.com/gh_mirrors/go/google-api-python-client点击查看免费下载导读本文以 google-api-python-client 官方仓库根目录的 CONTRIBUTING.rst 为核心骨架系统讲解如何为这个 Google Discovery API 官方 Python 客户端库贡献代码从签署 CLA、Fork 并搭建本地开发环境到使用nox驱动单元测试/系统测试、满足 black 与 flake8 代码风格检查、维护 100% 语句覆盖率、同步更新文档与 samples直至提交 Pull Request 的完整流程。读完本文你将掌握一套可直接照做的贡献工作流并能结合仓库中的 noxfile.py、setup.py 与 samples/compute/noxfile.py 等源码级证据理解每条规范背后的落地机制。一、贡献流程总览从 CLA 到 Pull RequestCONTRIBUTING.rst 开篇给出了四条核心贡献步骤这是所有贡献者必须遵循的基线流程签署贡献者许可协议CLA在提交任何代码之前完成具体协议类型见本文最后一节Fork 仓库在本地开发并测试代码改动同时补充文档编写清晰的 Commit Message让提交信息能够准确描述变更内容发送 Pull Request提交前建议阅读社区维护的 “Faster Pull Request Reviews” 最佳实践指南。仓库中与这一流程配套的辅助文件可以进一步印证.github/CONTRIBUTING.md更精简的贡献说明同样强调所有提交包括项目成员都需经过 PR 评审.github/PULL_REQUEST_TEMPLATE.mdPR 模板要求先针对改动开 issue 讨论设计、确保测试与 lint 通过、覆盖率不下降若改了源码、必要时同步更新文档——这与 CONTRIBUTING.rst 的“特性必须同时写进 API 文档和叙述性文档”的要求完全一致CODE_OF_CONDUCT.md 与 SECURITY.md分别规定了社区行为准则与安全问题上报渠道参与贡献前建议一并阅读。提示当前仓库为只读镜像本文所有命令仅用于说明贡献者在自己的 Fork 副本上的操作方式请勿在镜像仓库内直接执行修改性操作。二、新增特性Adding Features的硬性门槛在动手实现一个新特性之前CONTRIBUTING.rst 明确了三条硬性标准必须同时补齐两类文档特性既要在 API 文档指随 discovery 文档生成的接口说明中体现也要在叙述性narrative文档中说明必须完整跑通 CPython 3.10、3.11、3.12、3.13、3.14且同时覆盖 UNIX 与 Windows 平台不得引入不必要的依赖“不必要”虽主观但任何新增依赖都应先在社区讨论。从源码结构看这三条要求都在仓库配置中落地setup.py 第 72 行python_requires3.10第 77-83 行的 classifiers 逐一声明了Programming Language :: Python :: 3.10到3.14与文档宣称的支持版本严格对齐noxfile.py 第 50-59 行的nox.options.sessions默认会依次执行unit-3.10至unit-3.14、lint、format、scripts六类会话从工具链层面强制了“多版本必须通过”这一门槛第 36-48 行的test_dependencies列表django、google-auth、mox、parameterized、pyopenssl、pytest、pytest-cov、webtest、coverage 等就是单元测试的标准依赖集新增特性如需额外依赖通常也应先在列表中讨论。三、搭建本地开发环境Using a Development CheckoutCONTRIBUTING.rst 推荐的开发方式是基于 Git checkout 创建独立环境步骤如下$ cd ${HOME} # 将你的 Fork 克隆到本地目录名建议为 hack-on-google-api-python-client $ git clone gitgithub.com:USERNAME/google-api-python-client.git hack-on-google-api-python-client $ cd hack-on-google-api-python-client # 配置 upstream 远端以便拉取官方仓库的更新 $ git remote add upstream gitgithub.com:googleapis/google-api-python-client.git # 从 upstream 拉取并合并最新 main 分支 $ git fetch upstream $ git merge upstream/main完成上述操作后本地仓库即形成“push 到自己的 GitHub 仓库 → 从自己的仓库发起 PR”的标准工作流。官方建议使用nox驱动测试也允许使用自建的virtualenv。作为补充仓库根目录还提供了两条与开发环境相关的线索Makefile提供了pep8对googleapiclient与samples下的 Python 文件执行pep8 --ignoreE111,E202、testtox、coverage、docs、release等传统目标是 nox 之外的可选入口.github/workflows/main.ymlCI 中用于定时更新 discovery artifacts 的工作流其Set up Python 3.14步骤说明项目主线已运行在 Python 3.14 之上与 noxfile.py 第 34 行DEFAULT_PYTHON_VERSION 3.14互相印证。四、用 nox 运行测试单元测试与系统测试4.1 单元测试# 运行全部单元测试 $ nox -s unit # 仅在 Python 3.14 下运行单个测试按测试名过滤 $ nox -s unit-3.14 -- -k name of test结合 noxfile.py 的实现unit会话的细节远比命令本身丰富第 99 行unit会话在[3.10, 3.11, 3.12, 3.13, 3.14]五个版本上分别执行第 100-109 行nox.parametrize(oauth2client, [None, oauth2client2dev, ...])还会用五种 oauth2client 组合做参数化测试验证与历史依赖版本的兼容性第 119-122 行会先python3 setup.py bdist_wheel构建并安装 wheel 产物再从临时目录运行测试——这正是文档所说的“在独立目录中测试包产物”第 124-125 行安装testing/constraints-version.txt约束文件如 testing/constraints-3.10.txt 会固定httplib20.19.0、google-auth1.32.0等旧版本依赖用于验证“旧依赖 新代码”的下限兼容场景第 133-144 行以py.test --covgoogleapiclient --cov-fail-under85执行 tests 目录下全部测试覆盖率低于 85% 即失败。tests/目录下目前包含 test__auth.py、test__helpers.py、test_channel.py、test_discovery.py、test_http.py、test_model.py 等 13 个测试模块覆盖了认证、发现文档解析、HTTP 传输、模型序列化、schema 校验等核心子系统tests/data 中则存放了 discovery 文档、证书、密钥等测试夹具。4.2 系统测试# 运行全部系统测试 $ nox -s system # 在 Python 3.10 下运行单个系统测试 $ nox -s system-3.10 -- -k name of testCONTRIBUTING.rst 特别说明系统测试只配置在 Python 3.10 下运行为求便捷不在更老的 Python 3 版本上执行。并且仅执行命令并不会真正跑起来——系统测试会针对一个真实的 Google Cloud 项目发起请求需要尽可能使用gcloud的本地凭证参考应用认证最佳实践中“本地开发与测试”部分部分测试要求服务账号service account需按生产环境认证方式配置。一个务实的建议是本地开发阶段以nox -s unit为主系统测试通常留给 CI 或持有真实项目凭证的环境执行。4.3 关于nox -s cover的说明CONTRIBUTING.rst 提到可用nox -s cover检查覆盖率。从当前仓库 noxfile.py 的源码结构看文件中实际定义的会话是unit、lint、format、scripts四类并未单独注册名为cover的会话覆盖率门槛实际由unit会话内的--cov-fail-under85第 141 行以及scripts会话的--cov-fail-under90第 161 行强制保证。如果你在本地执行nox -s cover报“会话不存在”可改用nox -s unit并在其内部通过--cov参数获取覆盖率报告。五、常见编译错误Python.h 找不到如果你在安装依赖或构建过程中遇到报错提到找不到Python.h说明系统缺少 Python 开发头文件安装python-dev后重试即可。Debian/Ubuntu 下的命令为$ sudo apt-get install python-dev该错误通常出现在需要编译 C 扩展的依赖如pyopenssl、cryptography二者均在 noxfile.py 第 42-43 行的测试依赖列表中安装阶段。六、代码风格black 自动格式化 flake8 静态检查CONTRIBUTING.rst 对代码风格的要求可以概括为“自动格式化先行、静态检查兜底、提交钩子收尾”6.1 black 自动格式化仓库使用自动代码格式化工具black通过 nox 会话blacken一键运行可消除大部分 lint 报错$ nox -s blackennoxfile.py 第 20 行将 black 版本固定为black23.7.0第 22-32 行的BLACK_PATHS覆盖了apiclient、googleapiclient、scripts、tests以及describe.py、expandsymlinks.py、owlbot.py、setup.py等根目录脚本。6.2 flake8 静态检查PEP8PEP8 合规是硬性要求linter 配置中定义的例外除外$ nox -s lint从 noxfile.py 第 65-76 行可以看到lint会话的具体行为安装flake8后对googleapiclient与tests两个目录执行--selectE9,F63,F7,F82即仅针对“致命”语法/逻辑类错误并输出统计。若想加速本地 lint可设置两个环境变量指定最权威的对照版本所在位置export GOOGLE_CLOUD_TESTING_REMOTEupstream export GOOGLE_CLOUD_TESTING_BRANCHmain其中upstream应指向官方googleapis的 checkout分支应为该远端默认分支main。6.3 pre-commit 提交钩子仓库已内置 pre-commit 工具配置可在每次git commit时自动执行 linter 检查$ pre-commit install pre-commit installed at .git/hooks/pre-commit6.4 PEP8 的例外约定文档明确了两处被认可的风格例外均为测试代码专用_call_fut单元测试中常用的辅助方法名“FUT”即 Function-Under-Test被测函数虽不符合 PEP8 命名规范但更具可读性MUT部分测试中的局部变量Module-Under-Test被测模块。读者可在 tests 目录的测试模块中看到这类命名约定在实际代码中的运用。七、测试覆盖率的硬性要求CONTRIBUTING.rst 提出了一条非常严格的规定每次提交后代码库必须保持 100% 语句覆盖率statement coverage。就当前仓库的落地情况而言.coveragerc 定义了覆盖率报告的排除规则*/samples/*与describe.py被 omit后者因 issue #2132 暂未覆盖并利用pragma: NO COVER与def __repr__等exclude_lines排除不可测分支如前所述noxfile.py 的unit会话以--cov-fail-under85作为硬门槛——即当前基线要求为不低于 85%而文档宣称的“100% 语句覆盖”更接近长期目标与提交纪律而非单次 CI 的强制值。贡献者在提交前应至少确保自己的改动不降低现有覆盖率这一点也写进了 .github/PULL_REQUEST_TEMPLATE.md。八、文档同步更新与 HTML 文档构建如果你修复的 bug 涉及 API 或行为变更那么包内所有引用该 API 或行为的文档都必须同步修改且理想情况下与 bug 修复处于同一提交中。构建文档的命令为$ nox -s docs需要说明的是当前 noxfile.py 中并未注册docs会话仓库中承担文档构建任务的实际入口是 Makefile 的docs目标cd docs; ./build后执行python describe.py生成 docs/dyn 下的各 API 动态文档。如果你执行nox -s docs未命中可改用make docs。九、Samples 与代码片段贡献示例代码的规范代码示例统一存放在 samples 目录下目前包含 adexchangebuyer、analytics、appengine、compute、plus、youtube 等 20 余个示例子目录。CONTRIBUTING.rst 的要求是欢迎提交更多示例但必须为示例编写测试每个存放示例代码的文件夹都需要自己的noxfile.py脚本来自动化测试新建文件夹时可参考samples/snippets的模板提供noxfile.py与 requirements 文件示例测试同样运行在真实的 Google Cloud 项目上配置方式与系统测试一致。运行示例测试的命令# 运行某文件夹下的全部测试 $ cd samples/compute $ nox -s py-3.10 # 运行单个示例测试 $ cd samples/compute $ nox -s py-3.10 -- -k name of test从 samples/compute/noxfile.py 可以看出这套示例测试模板的完整机制第 41-60 行的TEST_CONFIG字典提供了可配置钩子通过gcloud_project_env默认读取GOOGLE_CLOUD_PROJECT环境变量指定要使用的云项目贡献者可复制该文件为noxfile_config.py后自行覆盖配置第 89 行ALL_VERSIONS [3.10, 3.11, 3.12, 3.13, 3.14]与主库版本矩阵保持一致第 184-237 行的_session_tests会递归收集*_test.py/test_*.py测试文件安装requirements.txt与requirements-test.txt并注入GOOGLE_CLOUD_PROJECT后执行 pytest第 129-139 行的lint会话使用--max-complexity20、--max-line-length88等参数对示例代码做 flake8 检查。此外scripts/readme-gen 下的readme_gen.py被readmegen会话调用负责根据*.rst.in模板生成示例的 README说明示例目录通常还包含由模板生成的文档文件。十、关于 README 与 PyPI 描述的特殊说明CONTRIBUTING.rst 提醒项目在 PyPI 上的描述直接取自 README。由于 PyPI 使用 reStructuredTextrst解析器README 中那些在 GitHub 上可以正常工作的相对链接例如写CONTRIBUTING.rst而不是指向 GitHub blob 的完整 URL在 PyPI 渲染时可能造成链接解析或显示问题。这一机制在 setup.py 中可以直接看到第 51-53 行读取根目录 README.md 作为long_description第 67 行声明long_description_content_typetext/markdown。也就是说当前 README 采用 Markdown 格式并被直接发布到 PyPI贡献者在修改 README 时应同时留意 Markdown 与 rst 解析器的差异。十一、支持的 Python 版本与版本策略11.1 支持版本矩阵项目当前支持 CPython 3.10、3.11、3.12、3.13、3.14 五个版本UNIX 与 Windows。这一声明有双重源码证据setup.py 第 72 行python_requires3.10与第 77-83 行的 classifiersnoxfile.py 第 50-59 行的默认会话矩阵与第 99 行unit会话的 Python 版本列表以及 testing 目录下与之对应的constraints-3.7.txt至constraints-3.14.txt约束文件其中 3.7/3.8/3.9 的约束文件仅为历史遗留。项目明确决定从 3.10 起支持 Python 3理由包括鼓励使用最新的 Python 3 版本、追随主流开源项目的步伐以及 Unicode 字面量支持PEP 414带来的更干净、同时适用于 Python 2/3 的代码库。注意 setup.py 第 24-26 行会在低于 3.10 的环境直接报错退出因此旧版本 Python 用户无法安装当前版本的库。11.2 版本号策略语义化版本本项目遵循 Semantic Versioning语义化版本MAJOR.MINOR.PATCH三段式版本号其中MAJOR位递增表示不兼容的 API 变更。文档同时提醒部分包目前仍处于主版本零0.y.z阶段这意味着任何时刻都可能发生破坏性变更公共 API 不应被视为稳定。发布历史可参考仓库根目录的 CHANGELOG.md超过 1.8MB记录了历次版本变更。十二、贡献者许可协议CLA接受 PR 的前置条件在接受你的 Pull Request 之前必须签署贡献者许可协议二选一个人 CLAIndividual CLA适用于以个人身份编写原创源代码、且拥有该知识产权的情况公司 CLACorporate CLA适用于受雇于某家公司、公司允许你贡献工作成果的情况。两种协议均可在线电子签署页面底部即可完成。签署完成后维护团队即可开始受理你的 PR。这一点在 .github/CONTRIBUTING.md 中亦有呼应通常只需签署一次 CLA即使为不同项目贡献也无需重复签署。结语一次高质量贡献的完整检查清单综合 CONTRIBUTING.rst 与仓库源码一次合规贡献应逐项确认☐ 已签署个人或公司 CLA☐ 在 Fork 副本上开发git remote add upstream已配置并已git merge upstream/main同步主线☐ 新特性已补齐 API 文档与叙述性文档☐ 通过nox -s unit含 3.10–3.14 五个版本且覆盖率不下降涉及真实云资源的改动同步通过系统测试☐nox -s blacken完成 black 格式化nox -s lint通过 flake8 检查必要时设置GOOGLE_CLOUD_TESTING_REMOTE/GOOGLE_CLOUD_TESTING_BRANCH加速☐ 已执行pre-commit install启用提交钩子☐ 示例代码放入 samples 对应目录并配套noxfile.py测试☐ Commit message 清晰描述变更最后发送 PR 并对照 .github/PULL_REQUEST_TEMPLATE.md 逐项打勾。按此流程操作你的贡献就能顺畅地进入评审与合并阶段。赞分享后端【免费下载链接】google-api-python-client The official Python client library for Googles discovery based APIs.项目地址https://gitcode.com/gh_mirrors/go/google-api-python-client点击查看免费下载相关推荐django-allauth 贡献者开发指南开发环境搭建、测试矩阵与代码质量保障django allauth 贡献者开发指南开发环境搭建、测试矩阵与代码质量保障 本指南以 django allauth 仓库根目录下的 CONTRIBUTI后端认证鉴权身份认证guidance 仓库贡献开发指南开发环境搭建、测试矩阵扩展与 Ruff 代码规范guidance 仓库贡献开发指南开发环境搭建、测试矩阵扩展与 Ruff 代码规范 本指南面向希望向 guidance 仓库提交代码、新增模型测试或参与维护的大模型提示工程AI Agentredis-py 贡献者指南从开发环境搭建、测试矩阵到代码审查的完整参与流程redis py 贡献者指南从开发环境搭建、测试矩阵到代码审查的完整参与流程 redis py 是 Redis 官方的 Python 客户端库覆盖同步客户端后端数据库客户端缓存上一篇为什么选择 linear-merge-openmind三大 SOLAR 模型融合的独特优势解析下一篇CANN/catlass间隔数据拷贝GM到L1创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考