Web3区块链【免费下载链接】web3.pyA python interface for interacting with the Ethereum blockchain and ecosystem.项目地址https://gitcode.com/gh_mirrors/we/web3.py点击查看免费下载web3.py 是 Python 生态中与以太坊区块链交互的核心库。本文基于仓库中的 docs/contributing.rst 贡献指南完整梳理从 fork 仓库、搭建开发环境、运行与编写测试、管理测试合约与 Geth Fixture到提交 PR、生成 release notes 与发布新版本的端到端流程并结合仓库中的Makefile、pyproject.toml、.pre-commit-config.yaml、tox.ini等真实配置给出可复制、可运行的命令。读完本文你将掌握成为一名合格的 web3.py 贡献者所需的全套开发与发布技能。一、贡献方式概览先想清楚再动手web3.py 的贡献不限于写代码也欢迎不写代码的贡献方式不写代码也可以贡献在 GitHub issues、Stack Overflow 或 Python Discord 服务器中解答用户问题撰写或录制教程内容改进文档包括修正拼写错误在 GitHub 上提交 issue 报告 bug尽量包含复现步骤与异常信息等细节。写代码的贡献方式修复 issue 中报告的 bug实现 issue 中已记录的功能补充缺失的测试用例。官方在指南中用醒目的 warning 强调了一个关键原则动手前务必先在 issue 中确认改动是否被期望采纳并告知你计划做什么。这可以避免在无法被接受的改动或重复劳动上浪费时间——这是社区项目贡献中最容易踩的坑。二、开发环境搭建fork、clone 与依赖安装官方强烈建议使用虚拟环境以最小化依赖冲突。所有 Pull Request 都从仓库的 fork 发起请先在 GitHub 界面上创建自己的 fork。由于 web3.py 依赖 submodules克隆时必须带上--recursive标志$ git clone --recursive your-fork-url/web3.py.git $ cd web3.py接着安装全部开发依赖并注册 pre-commit 钩子$ python -m pip install -e .[dev] $ pre-commit install[dev]是一个聚合的 extras从 setup.py 可以看到它等于docs、test、tester三组依赖再加上build、bump_my_version、ipython、twine等发布与调试工具的组合。也就是说一条命令就能装齐文档构建、测试、eth-tester 后端与发布工具链。仓库根目录的 Dockerfile 展示了官方推荐的开发基准环境基于python:3.13镜像安装libssl-dev复制web3、tests、ens源码后执行pip install -e .[dev]。本仓库的 pyproject.toml 中 mypy 配置的python_version3.10而 setup.py 声明python_requires3.10, 4tox.ini 的测试矩阵覆盖 Python 3.10 至 3.14贡献前请确认本机 Python 版本在支持范围内。使用 Docker 沙箱Docker 不是必需的但如果你偏好这种工作流可以直接使用 docker-compose.yml 中提供的sandbox容器——它基于 Dockerfile 构建通过 volume 把当前目录挂载到容器内并保持进程常驻$ docker compose up -d这会构建一个配置好可运行 Python 测试代码的容器。在本地运行核心测试$ docker compose exec sandbox bash -c pytest tests/core容器内没有安装go-ethereum因此跑集成测试时需要排除相关用例$ docker compose exec sandbox bash -c pytest tests/integration -k not goethereum任意命令都可以用bash -c前缀在容器内执行例如$ docker compose exec sandbox bash -c pwd ls想进入容器的交互式 shell运行$ docker compose exec sandbox bash三、运行测试从全量套件到精准子集运行测试是探索代码库的最佳方式之一。先安装测试依赖$ python -m pip install -e .[test][test]extras 在 setup.py 中包含pytest、pytest-asyncio、pytest-mock、pytest-xdist、flaky、hypothesis、tox、mypy与pre-commit并自动叠加tester组eth-tester[py-evm]与py-geth。运行全部测试$ pytest但官方明确指出全量测试耗时极长、通常不切实际。更常见的做法是只跑一个子集例如$ pytest tests/core/eth-module/test_accounts.pytox.ini 也给出了 CI 视角的测试矩阵py{310,311,312,313,314}对应ens、core、lint、wheel环境再加上integration-{goethereum,ethtester}、docs、benchmark环境核心测试还按-m not asyncio与-m asyncio拆分并行执行-n auto --maxprocesses15。lint 检查由 CI 执行也会在每个 commit 时本地触发。提前手动检查 lint 错误可以节省大量时间$ make lintMakefile 中该目标实际执行pre-commit run --all-files --show-diff-on-failure若第一轮自动修复仍有残留会再跑一遍确认。务必理解每个 PR 都必须在 CI 中通过完整测试套件套件会在 PR 打开或更新时自动运行。四、编写测试遵循既有结构与惯例项目强烈鼓励贡献者为代码编写高质量测试并建议复用现有测试作为指引保持测试风格的统一性。测试框架是pytest在 pytest 范围内conftest.py 用于存放同一目录及其子目录共享的公共代码与 fixture。单元测试与 eth-tester 测试单元测试与针对eth-tester库的测试以py-evm为后端经EthereumTesterProvider驱动分组存放于tests/下恰当的、按模块命名的子目录中核心部分位于 tests/core。新增测试时应尽量遵循现有结构并确保其存放位置合理——例如账户测试放在 tests/core/eth-module/test_accounts.py合约相关测试放在 tests/core/contracts。集成测试集成测试套件位于 tests/integration它依赖所谓的 fixtures注意这不是指 pytest fixtures。这些 zip 文件同样存放在 tests/integration 目录下如当前仓库中的tests/integration/geth-1.16.7-fixture.zip它们配置好要测试的客户端与创世配置为测试预置了解锁的、预充值余额的账户等可用对象。集成测试目录的角色划分如下客户端目录下的common.py如 tests/integration/common.py、tests/integration/go_ethereum/common.py存放跨所有 providerhttp、ipc、ws测试共享的代码主要用于覆写跨 provider 的测试各目录下的conftest.py存放可被同目录或子目录所有测试文件使用的代码主要是共享 pytest fixturestest_{client}_{provider}.py文件如tests/integration/go_ethereum/test_goethereum_http.py存放客户端与 provider 专属的测试配置主要用于覆写对应客户端的 provider 类型专属测试。集成测试各自独立运行以避免上下文污染正因为相互隔离可以用pytest-xdist并行化加速。使用-n标志指定 worker 数量例如 4 个 worker$ pytest tests/integration/go_ethereum/path/to/module/or/test -n 4值得留意的是虽然集成测试的运行配置散落在 tests/integration 各文件中但集成模块测试的用例本体却写在 web3/_utils/module_testing 下的各个模块中例如EthModuleTest、GoEthereumAdminModuleTest、NetModuleTest、Web3ModuleTest等基类见 web3/_utils/module_testing/init.pygeth 各 provider 的测试文件只是覆写其中与具体 provider 相关的部分。五、测试合约compile_contracts.py 的使用测试用合约位于 web3/_utils/contract_sources由同目录下的 compile_contracts.py 脚本编译。用法是在命令行传入要使用的 Solidity 版本脚本参数-v/--version编译合约所用的 Solidity 版本留空则使用 solcx 中最新可用版本。-f/--filename留空则编译所有.sol文件并生成对应合约数据传入具体.sol文件名则只编译单个文件。运行脚本需要py-solc-x编译与black代码格式化$ python -m pip install py-solc-x black编译全部合约并生成测试套件所用的合约数据生成在contract_sources下的contract_data子目录中$ cd web3/_utils/contract_sources $ python compile_contracts.py -v 0.8.17 Compiling OffchainLookup ... reformatted ...只编译一个.sol文件时用-f或--filename指定$ python compile_contracts.py -v 0.8.17 -f OffchainLookup.sol Compiling OffchainLookup.sol reformatted ...从脚本源码 compile_contracts.py 可以看到其内部逻辑用solcx.get_compilable_solc_versions()取得可用版本未指定时取排序后的最新版本随后solcx.install_solc()自动安装并set_solc_version切换编译器对每个合约生成BYTECODE、RUNTIME、ABI与汇总的*_DATA字典并自动给字节码补0x前缀、用 black 格式化输出文件。生成结果的真实样例可见 web3/_utils/contract_sources/contract_data/emitter_contract.py文件头部会记录由compile_contracts.py脚本生成、以 Solidity v0.8.30 编译的来源信息。若存在无法由脚本生成、但对集成测试至关重要的合约数据可以用contract_data子目录下的 _custom_contract_data.py 手工存放。⚠️ 运行脚本后务必重新生成集成测试 fixture以更新合约字节码详见下文生成新 Fixtures一节。六、手动测试未发布版本要在其他项目中导入并测试尚未发布的 web3.py 版本可以直接从开发目录安装$ python -m pip install -e ../path/to/web3py七、代码风格pre-commit 与类型检查项目用pre-commit强制统一代码风格该工具在每次 commit 时自动运行也可手动触发$ make lint如果需要跳过 pre-commit 检查提交可用git commit --no-verify。从 .pre-commit-config.yaml 可以看到实际启用的钩子链条包括check-yaml、check-toml、end-of-file-fixer、trailing-whitespace基础检查pyupgradePython 语法现代化--py38-plusblack代码格式化rev 23.9.1flake8含flake8-bugbear行宽 88autoflake清理未使用 importisortimport 排序pydocstyledocstring 规范选择 D2/D3/D4 并忽略一批有争议的规则见 pyproject.tomlmdformatMarkdown 格式化本地钩子mypy-localpython -m mypy -p web3要求全部开发依赖在场blocklint阻塞词扫描与check-rst-files禁止仓库根目录出现.rst文件。由于使用 Black若想在 git blame 中忽略引入 Black 的提交可配置$ git config blame.ignoreRevsFile .git-blame-ignore-revs仓库根目录的 .git-blame-ignore-revs 文件正是为此准备的。本库使用类型提示由mypy强制执行作为 pre-commit 检查的一部分。所有新代码都必须携带类型提示tests目录内的代码除外。mypy 的严格配置disallow_untyped_defs、disallow_any_generics、strict_equality等见 pyproject.toml。八、文档与 Pull Request良好的文档能加速采纳并带来更满意的用户。每次 PR 都会在 Read the Docs 上生成最新文档的独立预览地址形式为https://web3py--pr-number.org.readthedocs.build/en/pr-number/。关于 PR 的几个实用建议尽早发起 PR。PR 代表一段讨论的开始不一定要是最终成品发起 PR 后关注 CI 构建状态确保所有测试通过。通常未通过 CI 的 PR 不会被评审除非显式请求若改动需要体现在 release notes 中请添加newsfragment文件规则详见 newsfragments/README.md尽量让 release notes 的改动与引入该 feature/bugfix 的提交放在一起。newsfragment 命名规则newsfragment 是放在 newsfragments 目录下的短文件每份包含一段 ReST 格式文本将被合入下一版 release notes描述对用户有影响的改动方面。命名格式为ISSUE.TYPE.rst其中TYPE必须是 pyproject.toml 中 towncrier 配置的九种类型之一TYPE含义是否显示内容breaking破坏性变更是bugfix缺陷修复是deprecation弃用声明是docs文档改进是feature新功能是internal面向贡献者的内部改动是misc杂项改动否performance性能改进是removal移除项是例如123.feature.rst、456.bugfix.rst。如果 PR 修复了某个 issue 就用该 issue 编号没有对应 issue 就先开 PR 再使用 PR 编号。towncrier 会自动重排文本不必做花哨排版可用towncrier build --draft预览 release notes 的最终效果。配套的 newsfragments/validate_files.py 用于校验文件命名是否合法只允许上述九种扩展名及validate_files.py、README.md两个白名单文件并支持is-empty参数用于发布前确认 newsfragment 已全部消费完毕。九、生成新的 Geth Fixtures集成测试基于 Geth 私链。每当引入新版本的客户端软件时就需要生成新的 fixtures。什么是 fixture它是一条预同步的网络配置并运行客户端、部署测试合约、保存最终状态以供 web3.py 功能测试使用。生成前先确保已安装测试依赖$ python -m pip install -e .[test]Geth Fixtures 生成步骤安装所需 Geth 版本。官方推荐使用py-geth因为它能轻松管理多个 Geth 版本。注意py-geth本身也需要随每个新 Geth 版本更新历史提交可作模板。若 py-geth 已支持所需版本例如$ python -m geth.install v1.16.7指定 Geth 二进制并运行 fixture 生成脚本在 web3.py 目录内$ GETH_BINARY~/.py-geth/geth-v1.16.7/bin/geth python ./tests/integration/generate_fixtures/go_ethereum.py从 tests/integration/generate_fixtures/go_ethereum.py 的入口可以看到脚本要求必须设置GETH_BINARY环境变量否则直接抛错随后从二进制路径中正则提取版本号生成 zip、删除旧 fixture并自动更新多处版本引用。产物是 zip 文件存放在 tests/integration 目录下。脚本会自动更新 tests/integration/go_ethereum/conftest.py其中的GETH_FIXTURE_ZIP geth-1.16.7-fixture.zip与 web3/tools/benchmark/node.py 指向新 fixture同时更新 .circleci/config.yml 的geth_version默认值与 docs/contributing.rst 中的示例命令并删除旧 fixture见update_circleci_geth_version、update_fixture_generation_version、update_doc_version、remove_old_fixtures的实现。运行测试。为确保本地以正确的 Geth 版本运行可再次带上GETH_BINARY环境变量$ GETH_BINARY~/.py-geth/geth-v1.16.7/bin/geth pytest tests/integrationCI 版本参数同步。.circleci/config.yml 中的geth_version与pygeth_version参数默认值会被脚本自动更新为生成 fixture 所用的 go-ethereum 版本及支持安装它的 py-geth 版本。fixture 生成脚本的底层行为也值得了解在 tests/integration/generate_fixtures/common.py 中定义了固定的创世配置chainId 为字符串web3py对应的整数131277322940537、从 homestead 到 prague 的硬分叉区块/时间点、预置大额余额的 coinbase 与 keyfile 账户等脚本通过 IPC 连接 Geth部署 Math、Emitter、Revert、OffchainLookup、PanicErrors、Storage 等测试合约产生带日志的区块、空区块、带交易区块等链上状态最后打 zip 存档。十、CI 测试夜间版 Geth 构建偶尔需要让 CI 对未发布的 Geth 版本跑测试套件例如测试即将到来的硬分叉改动。以下流程仅用于测试正式合入 main 需等 Geth 正式发布并将测试更新到新稳定版按需配置 tests/integration/generate_fixtures/go_ethereum/common.pyGeth 会对每个合并入代码库的提交自动编译新构建从 develop builds 页面下载所需构建通过GETH_BINARY传入刚下载的二进制构建测试 fixture别忘了更新 tests/integration/go_ethereum/conftest.py 指向新 fixture由于 CI 运行在 Ubuntu 上下载对应的 64 位 Linux develop 构建放到 web3.py 目录根部并重命名为custom_geth在 .circleci/config.yml 中把geth_versionpipeline 参数改为custom触发 CI 使用自定义 Geth 构建跑测试套件创建 PR让 CI 运行即可。十一、发布流程从预检到推送到 PyPI发布通常从main分支进行发布 beta 时 beta 从main发布而之前的稳定分支则从该分支发布。发布前的最终测试发布新版本前构建并测试将要发布的包$ git checkout main git pull $ make package-testmake package-test会先clean清理构建产物用python -m build构建包再通过 scripts/release/test_package.py 将包安装到临时虚拟环境中按提示激活 venv 后测试你认为重要的功能。复查将要发布的文档$ make docs校验并预览 release notesmake docs内部也会先跑一遍校验$ make validate-newsfragments该目标运行 newsfragments/validate_files.py 检查命名合法性并用towncrier build --draft --version preview生成草稿预览见 Makefile。构建 release notes在 bump 版本号之前构建 release notes必须指定要 bump 的版本部分它决定版本号在 release notes 中的展示方式$ make notes bump$$VERSION_PART_TO_BUMP$$出错就重跑make notes直到成功。从 Makefile 看该目标先用bump-my-version bump --dry-run计算出即将到达的版本号再以该版本号运行towncrier build --yes消费 newsfragments、构建文档并提交一个Compile release notes的 commit。推送到 GitHub 与 PyPI确认发布包无误后发布新版本$ make release bump$$VERSION_PART_TO_BUMP$$该命令会见 Makefile按bump参数在 pyproject.toml 与 setup.py 中 bump 版本号为新版本创建 git commit 与 tag构建包将 commit 与 tag 推送到 GitHub将新包文件推送到 PyPI。执行前还需满足前置校验bump必须设置否则check-bump报错且必须存在指向ethereum/web3.py的名为upstream的 remote否则check-git报错并退出。发布流程还会临时强制开启 GPG commit 签名保留并恢复原有commit.gpgSign设置并确认 newsfragment 目录已清空。选择要 bump 的版本部分$$VERSION_PART_TO_BUMP$$必须是以下之一major、minor、patch、stage或devnum。版本格式见 pyproject.toml 的 bumpversion 配置稳定版为{major}.{minor}.{patch}非稳定版为{major}.{minor}.{patch}-{stage}.{devnum}stage为alpha或beta。当前仓库版本为8.0.0-beta.2。处于 beta 版本时make release bumpstage会切换到稳定版当前为稳定版却要发布非稳定版时需显式指定新版本如$ make release bump--new-version 4.0.0-alpha.1可用bump-my-version show-bump预览 bump 任意版本部分后的结果。小结web3.py 的贡献流程覆盖了代码质量、测试、文档与发布的全链路pre-commit钩子链Black、flake8、isort、mypy 等在本地即强制代码规范pytest分层组织单元测试与 geth 集成测试配合pytest-xdist并行加速compile_contracts.py一键从 Solidity 源码生成测试合约数据Geth Fixture 生成脚本能自动化同步测试配置、CI 参数与文档最后经由 newsfragment towncrier 汇聚 release notes通过make package-test与make release完成发布。理解这条流水线无论你打算修 bug、加功能还是补测试都能找到自己的切入点并保证改动顺利通过 CI 合入主线。赞分享Web3区块链【免费下载链接】web3.pyA python interface for interacting with the Ethereum blockchain and ecosystem.项目地址https://gitcode.com/gh_mirrors/we/web3.py点击查看免费下载相关推荐Slate 贡献指南从环境搭建、测试验证到版本发布的完整开发实践Slate 贡献指南从环境搭建、测试验证到版本发布的完整开发实践 本文是围绕开源富文本编辑器框架 Slate当前处于 beta 阶段仓库编写的贡献指南系前端富文本UI组件把二手 X96 Max 变成 2 瓦 Linux 服务器Amlogic S905X3 Armbian 移植踩坑全记录把二手 X96 Max 变成 2 瓦 Linux 服务器Amlogic S905X3 Armbian 移植踩坑全记录 现在它是电视柜角落里一台 2 瓦的网关嵌入式开发工具构建工具操作系统明日方舟日常自动化繁琐事务如何交给 MAA 代劳明日方舟日常自动化繁琐事务如何交给 MAA 代劳 MAAMaaAssistantArknights是《明日方舟》的自动化工具用图像识别看懂游戏画面计算机视觉GUI自动化RPA上一篇【亲测免费】 gRPC Health Probe 项目常见问题解决方案下一篇GitHub MCP ServerAI驱动的GitHub自动化管理平台创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
