包管理器开发工具【免费下载链接】pipThe Python package installer项目地址https://gitcode.com/gh_mirrors/pi/pip点击查看免费下载本文是面向 pipPython 包安装器开发者的贡献指南覆盖 PR 提交规范、AI 生成代码政策、自动化测试、NEWS 变更日志条目的编写规则、分支同步工作流以及从贡献者走向维护者的成长路径。读完本文你将掌握在 pip 仓库根目录即本仓库源码位于 src/pip中提交合规且可被快速合并的 Pull Request 的完整实操流程并能独立完成一条符合 towncrier 规范的 NEWS 条目。pip 内部架构导读在深入贡献之前建议先了解 pip 的内部结构。pip 有一个持续更新的 内部架构指南包含总体概览overview、源码解剖anatomy、配置文件体系、包查找package-finding、命令行接口设计与升级选项等子章节在你初次接触代码库时非常有帮助。从源码目录结构看pip 的核心实现集中在 src/pip/_internal 下按职责拆分为cli命令行解析、commands各子命令实现、index包索引与查找、metadata包元数据、network网络与会话、operations安装/卸载等操作、req需求解析与构建、resolution依赖解析含 legacy 与 resolvelib 两条路径、utils与vcs等模块第三方依赖以 vendoring 方式固化在 src/pip/_vendor 中。注意架构文档明确提示pip 内部 API 不受支持随时可能变化因此以第三方方式直接 importpip._internal并不被鼓励。AI 政策LLM 工具的使用边界pip 项目并不禁止贡献者使用 LLM 工具但要求遵守专门的 AI_POLICY.md其核心原则是每一项贡献都必须由一位真正理解代码、拥有其版权并愿意为之负责的人类背书。具体包括PR 中不得出现 LLM 机器人的Co-authored-by:署名带有 LLM 联合作者署名的 PR 会被直接关闭因为这会危及项目的版权状态提交 PR 即表示你承诺你是作者或拥有合法的提交权利理解提交的代码并对它负全部责任——这是 LLM 写的不是对评审问题的合格回答禁止无监督的 agentic 工具如自动批量提交 PR 的机器人账号重复的低质量slop贡献会被关闭且不再评审行为类似机器人的账号会被永久封禁LLM 生成的评论必须简洁、准确并随时准备好为之辩护冗长、重复或离题的评论可能被标记为垃圾信息。提交 Pull Request 的规范目标分支与基本要求所有 PR 都提交到main分支并附带清晰的描述做了什么、为什么。你必须有法律上的许可来分发所贡献的代码且代码必须可在 MIT License 下分发LICENSE.txt。必须为改动提供测试并先在本地运行测试。pip 官方支持多个 Python 版本与操作系统见下文自动化测试任何 PR 都必须考虑并兼容所有这些平台。小而自洽控制 PR 规模评审质量会随补丁规模增大而下降因此PR 应当保持小、自洽、范围受限一个大型功能往往需要拆成多个小 PR 分批落地PR不应充当功能分支即不要在 PR 内部持续进行开发迭代而应拆解成可独立评审、独立合并的小部分避免夹杂与本次改动无关的外观性修改如重排注释/文档中的文本、增删空行或行内空白这类清理可单独作为 formatting cleanup PR 提交。注意贡献者可以使用任何开发工具但必须确保提交的代码满足项目要求并且足够理解自己提交的代码以回应评审意见。自动化测试与持续集成所有 PR 以及对main分支的合并都会基于.github/workflows下的工作流文件在 GitHub Actions 上自动测试详见 CI 文档。你可以在 PR 页面看到 CI 运行状态与结果若某个构建失败可通过 Details 链接查看输出。需要重跑 CI 时可关闭再重新打开 PR或向 PR 追加一次提交必要时维护者也可以手动重启某个 job/build。测试矩阵pip 的测试覆盖多种解释器、操作系统与架构详见 CI 文档解释器CPython 3.10、3.11、3.12、3.13、3.14、3.15以及最新的 PyPy3当前仓库 pyproject.toml 声明requires-python 3.10__pip-runner__.py中另有镜像副本操作系统Linux、Windows、macOS架构x64、x86、arm64仅 macOS。CI 检查项CI 运行的检查分为五类检查类型内容lint由.pre-commit-config.yaml定义的代码风格检查docs文档构建检查vendoring校验 src/pip/_vendor 目录是否为干净的 vendored 状态unittests/unit 下的单元测试integration主要位于 tests/functional 的集成测试package打包步骤验证其中 lint、docs、vendoring、package 只在 3 个操作系统的 x64 变体上运行即可只有单元测试与集成测试需要覆盖全部解释器组合。本地运行测试开发环境搭建与测试执行细节见 Getting Started 文档。pip 的测试用 pytest 编写、由 nox 驱动推荐并行运行以节省时间# 并行运行推荐 $ nox -s test-3.10 -- -n auto # 顺序运行 $ nox -s test-3.10 # 指定解释器版本如 3.15 或 pypy3 $ nox -s test-3.15nox 会将其余参数转发给 pytest因此可以使用 pytest 的各种选择方式例如按文件名、标记-m unit或关键字-k install and not wheel挑选测试。相关测试工具依赖pytest、pytest-xdist、virtualenv 等定义在 pyproject.toml 的[dependency-groups] test中pytest 的基础配置如--disable-socket、--ignoresrc/pip/_vendor等 addopts也在同一文件中。NEWS 条目每个非平凡改动都要写变更日志NEWS.rst文件由 towncrier 管理所有非平凡的改动都必须附带一条 news entry。towncrier 的配置条目目录、类型、渲染模板、issue 引用格式集中在 pyproject.toml 的[tool.towncrier]段条目目录为news/输出文件为NEWS.rst渲染模板为 tools/news/template.rst。如何创建 NEWS 条目先创建一个描述本次改动的 issuePR 本身可以充当该 issue但官方更推荐有独立 issue例如 PR 因代码质量问题被拒时仍有据可查取该 issue/PR 的编号在news/目录下创建一个以编号命名、后缀为类型名的文件news/number.type.rst。例如issue/PR 编号为1234且修复了一个 bug则创建news/1234.bugfix.rst。一个 PR 可以跨越多个类别比如同时新增功能并废弃旧功能就同时创建news/NNNN.feature.rst与news/NNNN.removal.rst若一个 PR 涉及多个 issue/PR可为每个编号创建内容完全相同的文件towncrier 会自动去重。当前仓库 news/ 目录中即有真实示例news/13084.bugfix.rst修复 zipapp 场景下 pip 自身版本检查报告环境旧版本而非运行中版本的问题news/14235.feature.rst通过不再解析每条PATH条目来加速安装带 console scripts 的 wheelnews/14160.trivial.rst 与 news/14177.trivial.rsttrivial 类型条目回归测试扩充等news/certifi.vendor.rst、news/distlib.vendor.rst、news/msgpack.vendor.rst、news/packaging.vendor.rst、news/platformdirs.vendor.rstvendor 类型条目以库名作为文件名键。条目内容规范条目是 reStructuredText 格式的文本渲染后作为NEWS.rst中的条目正文无需在正文里引用 issue/PR 编号towncrier 渲染时会自动附上所有相关 issue 的引用issue_format #{issue}格式链接文件末尾必须有一个换行。风格要求简洁、句子式大小写sentence case、少于 80 字符、祈使语气——一条合格的条目应当能补全句子 This change will ...。极少数单行不够的情况可以用一行祈使语气摘要 空行 一到多段描述每段按 80 字符换行。记住news 条目面向最终用户只应包含对用户有意义的细节。选择 NEWS 条目类型towncrier 在 pyproject.toml 中定义了七类条目渲染时按showcontent决定是否在NEWS.rst中展示内容其中 Trivial Changes 不展示类型目录在 NEWS.rst 中的分组说明removalDeprecations and Removals弃用与移除featureFeatures新功能bugfixBug Fixes缺陷修复vendorVendored Librariesvendored 库的升级/移除/新增docImproved Documentation文档改进processProcess流程、政策类变更不常用如版本方案变更、弃用政策更新trivialTrivial Changes不展示内容无需向用户播报的琐碎改动trivial 变更指不值得进入 news 文件的改动例如对公众无影响的代码重构、错别字修正、空白调整等。标记方法在news/目录下添加一个随机命名的空文件扩展名为.trivial.rst。POSIX 下可运行touch news/$(uuidgen).trivial.rstWindows PowerShell 下可运行New-Item news/$([guid]::NewGuid()).trivial.rst。核心维护者也可以给 PR 添加 skip news 标签达到同样效果。vendor 变更升级、移除或新增一个 vendored 库除了可能伴随的 feature/bugfix 等条目外还需用news/library.vendor.rst文件单独提及以库名为键可避免同一库更新两次时产生重复条目。可见当前仓库的五个 vendor 条目正是这一规范的体现。process 变更涉及流程、政策或其他非代码类的显著变化可使用news/name.process.rst通常不常用。保持分支同步fetch rebase 工作流main分支更新频繁工作期间至少需要同步一次。假设你的 Git 已配置好远程仓库运行git remote -v的输出形如origin https://github.com/USERNAME/pip.git (fetch) origin https://github.com/USERNAME/pip.git (push) upstream https://github.com/pypa/pip.git (fetch) upstream https://github.com/pypa/pip.git (push)其中USERNAME是你的 GitHub 用户名origin是你的 forkupstream是 pip 主仓库。首先从主仓库拉取最新变更$ git fetch upstream更新本地main分支并把上游变更 rebase 到其上$ git checkout main $ git rebase upstream/main此时可能需要解决合并冲突。解决后将本地main推送到你的origin$ git checkout main $ git push origin main更新特性分支时流程类似$ git checkout awesome-feature $ git fetch upstream $ git rebase upstream/main良好实践是把工作分支及时推到origin备份git push origin awesome-feature该操作不会创建 PR。分支再次需要更新时由于远端已有同名分支需强制推送$ git push -f origin awesome-feature-f/--force会用本地分支强制覆盖origin分支若该分支上有打开的 PR强制推送会更新该 PR评审要求修改后非常有用。若遇到如下报错通常意味着分支落后于远端重试push -f即可! [rejected] awesome-feature - awesome-feature (non-fast-forward) error: failed to push some refs to https://github.com/USERNAME/pip.git hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. Integrate the remote changes (e.g. hint: git pull ...) before pushing again. hint: See the Note about fast-forwards in git push --help for details.成为维护者想成为正式维护者先从小事做起参与 issue 分类triage。维护者会为活跃一段时间通常至少 2–3 个月且做出积极贡献的贡献者开放 issue 分类权限这是成为维护者的可选但强烈推荐的第一步。分类工作可参考 Issue Triage 指南其中介绍了 issue 跟踪器的标签体系C-类别、kind、OS-、project、resolution、state、type等前缀分类以及good first issue、S: needs triage、skip news、needs rebase or merge等独立标签和 issue 自动化流程如新 issue 自动打S: needs triage标签、关闭 30 天后锁定线程等。当你认为准备好了通常至少是开始分类 5 个月后联系任意一位维护者他们会启动现有维护者之间的投票。成为维护者后通常会获得以下权限GitHub Push 访问权限PyPI 发布访问权限CI 管理能力ReadTheDocs 管理能力。总结一份高质量贡献的检查清单通读 内部架构指南理解改动涉及的核心模块src/pip/_internal阅读并遵守 AI_POLICY.md确保对每一行代码负责将改动拆成小且自洽的 PR提交到main分支避免无关的外观性修改补充测试并在本地用nox -s test-3.10 -- -n auto等命令跑通参考 Getting Started为改动创建符合规范的 news/ 条目非 trivial 必填用git fetch upstream git rebase upstream/main保持分支同步必要时git push -f origin更新 PR在 PR 中清晰描述做了什么与为什么耐心回应评审意见。感谢你的贡献赞分享包管理器开发工具【免费下载链接】pipThe Python package installer项目地址https://gitcode.com/gh_mirrors/pi/pip点击查看免费下载相关推荐HackRF贡献者指南从Issue提交到Pull Request流程HackRF贡献者指南从Issue提交到Pull Request流程 作为开源软件无线电平台Software Defined Radio, SDR的领军项嵌入式硬件开发固件通信贡献 pytest从提交 Issue 到提交 Pull Request 的完整参与指南贡献 pytest从提交 Issue 到提交 Pull Request 的完整参与指南 本文基于 pytest 仓库的官方贡献文档 doc/en/contr测试开发工具在 refine 管理后台做数据检索全局防抖搜索与表格过滤的落地写法在 refine 管理后台做数据检索全局防抖搜索与表格过滤的落地写法 在 refine 搭建的管理后台里数据检索卡慢往往不是表格组件的问题而是搜索请求在前端企业应用上一篇CodeCombat开源许可证终极指南MIT与CC-BY在教育项目的完美融合下一篇三种排序算法可视化对比创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考