WinPython Zero 3.6.1.0 版本升级全解析：7 个核心包的变更明细与 changelog 自动生成机制

• 开发工具
• 构建工具
• CLI
• 包管理器

本文以 WinPython 仓库 changelogs 目录 中的官方变更记录 WinPythonZero-3.6.1.0_History.md 为主体，完整梳理精简发行版 WinPython Zero 从 3.6.0.2Zero 升级到 3.6.1.0Zero 过程中 7 个 Python 包的版本变更、每个包在发行版中的角色定位，并结合仓库源码 wppm/diff.py 与 wppm/wppm.py 还原这类 changelog 的自动生成原理。读完本文，你将掌握 Zero 变体的包构成、本次升级的全部细节，以及用wppm -diff复现任意两个版本间差异对比的方法。

背景：WinPython Zero 是什么

WinPython 是一个面向 Windows 平台的免费 Python 发行版，附带预编译的 Scientific Python 包。在 2016—2017 年的 3.6 时代，仓库同时维护多个变体，其中Zero是一个极简化的发行分支——这一点可以从它的包索引文件直接看出：

• changelogs/WinPythonZero-3.6.1.0.md 中"Tools" 一节为空，没有任何工具组件；
• 全部内容集中在 "Python packages" 一节，仅包含 17 个包：解释器本体、包管理工具链（pip、setuptools）、终端 REPL 生态（ptpython、prompt_toolkit、pygments、jedi）、少量数据库与解析库（pyodbc、sqlite_bro、pyparsing）以及发行版自身的辅助工具winpython包。

对照全功能版本动辄上百个预编译科学计算包的构成，Zero 变体仅保留"最小可用"的核心集合，可推断其定位是零额外工具、零重组件的最精简可运行发行版。

需要说明的是，从当前仓库的构建配置 winpython_builds.toml 看，现在的 flavor 体系（dot、dotf、slim、slimf、whl）中已不再包含Zero，且注释明确写着 "Not built at the moment: no python below lists it"。因此 Zero 属于历史发行分支，其版本记录全部沉淀在changelogs/目录下，供查询与版本对比使用。

升级总览：从 3.6.0.2Zero 到 3.6.1.0Zero

官方变更记录 WinPythonZero-3.6.1.0_History.md 以 "Upgraded packages" 列表形式记录了本次 7 个包的升级，全部集中在 Python 包层面（本次没有新增包、没有移除包、Tools 一节依旧为空）：

各升级包详解

1. 解释器本体：Python 3.6.0 → 3.6.1

这是本次升级中影响面最大的一项。Python 3.6.1 是 CPython 3.6 分支的维护版本，替换了上一发行版内置的 3.6.0，使整个 Zero 发行版的基础运行时向前推进一个补丁级别。在新索引 changelogs/WinPythonZero-3.6.1.0.md 中，Python条目始终位于包列表首位，是发行版中其他所有包的运行基石——jedi、pyodbc、pythonnet 等扩展模块的可用性都建立在该解释器版本之上。从源码层面看，Python包在 changelog 中是作为一个普通包条目被解析和比较的（见后文生成机制部分），并没有特殊豁免，因此解释器的版本升级会与普通第三方包一样如实反映在差异输出中。

2. 包管理工具链：setuptools 34.1.1 → 34.3.2

setuptools 是 Python 生态的构建与安装基础设施，负责包的分发元数据处理、依赖声明与安装脚本执行。本次从 34.1.1 升到 34.3.2，属于同系列内的快速跟进维护。在 Zero 的极简构成中，setuptools 与 pip 共同构成"包管理双子星"，其健康程度直接决定用户能否便捷地自行补充缺失的第三方包。

3. 补全与 REPL 生态：jedi 0.9.0 → 0.10.0

jedi 是一个纯 Python 实现的自动补全/静态分析库，其官方描述为 "An autocompletion tool for Python that can be used for text editors"。在 Zero 发行版中，jedi 是ptpython（基于 prompt_toolkit 的增强 REPL，版本 0.36）补全能力的关键依赖，同时服务于编辑器场景。本次从 0.9.0 跨入 0.10.0 主版本线，通常意味着补全引擎的行为与 API 有较大幅度的调整——由于发行版同时固定了ptpython与prompt_toolkit的版本，二者与新版 jedi 的组合兼容性正是这类发行版变更中最需要关注的联动点（从源码结构看，jedi 与 ptpython 在新索引中同时存在，可推断发行版对补全链路做了整体联调）。

4. 数据库访问：pyodbc 4.0.6 → 4.0.15

pyodbc 是 Python 访问 ODBC 数据库的标准 DB-API 模块（"DB API Module for ODBC"），在 Windows 生态下常用于连接 SQL Server、Access 等通过 ODBC 驱动暴露的数据源。本次升级幅度较大（4.0.6 → 4.0.15），跨越了多个小版本，属于功能与修复并重的实质性更新。这也是 Zero 发行版中除 sqlite_bro（0.8.11，一个单文件图形化 SQLite 客户端）之外仅有的数据库相关组件，二者共同覆盖"命令行/脚本操作 ODBC 数据源 + 图形化查看 SQLite"两个基本场景。

5. 解析与路径工具：pyparsing 2.1.10 → 2.2.0、appdirs 1.4.0 → 1.4.3

这两个包都是"小而关键"的底层基础设施：

• pyparsing从 2.1.10 升到 2.2.0（"A Python Parsing Module"）。pyparsing 是许多上层包用来实现 DSL、配置解析、表达式求值的通用解析库，本身不带复杂依赖，升级风险低、收益面广；
• appdirs从 1.4.0 升到 1.4.3（"A small Python module for determining appropriate platform-specific dirs, e.g. a 'user data dir'"）。它负责按平台规范计算用户数据目录、配置目录、缓存目录等路径，是众多应用感知 Windows%APPDATA%、%LOCALAPPDATA%等位置时的标准选择。尽管升级跨度只有 0.0.3，但对于依赖其路径计算行为的应用而言，1.4.3 修正的是跨平台路径判定的细节正确性。

6. .NET 互操作：pythonnet 2.2.2 → 2.4.0.dev0

pythonnet 是 Python 与 .NET / Mono 运行时互操作的桥梁（".Net and Mono integration for Python"）。本次升级有两个值得注意的细节：

• 版本号从 2.2.2 直接跳到2.4.0.dev0，跳过了 2.3 系列，说明发行版引入的是 2.4 开发线的最新快照；
• 版本号中带.dev0后缀，属于典型的预发布（dev）版本，意味着该组件并非正式发布版，而是跟随上游开发进度锁定的一版构建。

在 Zero 精简发行版中保留 pythonnet，使得用户在不额外安装任何组件的情况下，即可在 Python 中调用 .NET 程序集，这填补了"最小发行版"中面向 Windows/.NET 生态的互操作能力。

这份 changelog 是怎么自动生成的：wppm diff 机制

上文逐条解读的升级明细，并非人工手写，而是由 WinPython 自带的包管理工具wppm（WinPython Package Manager）通过版本对比自动生成的。仓库源码中保留了完整的实现，值得深入理解。

对比引擎：wppm/diff.py

wppm/diff.py 是 changelog 生成的"心脏"，核心逻辑分为三部分：

（1）包索引解析（Package与PackageIndex）

class Package: PATTERNS = [ r"\[([\w\-\:\/\.\_]+)\]\(([^)]+)\) \| ([^\|]*) \| ([^\|]*)", # SourceForge r"\[([\w\-\:\/\.\_]+) ([^\]\ ]+)\] \| ([^\|]*) \| ([^\|]*)" # Google Code ]

它用正则把索引文件里每一行包名 | 版本号 | 描述解析成一个Package对象；PackageIndex则按### Tools、### Python packages、### WheelHouse packages三个分区把包归类存放。这正是本关联文档中 "Python packages" 分区的来源。

（2）版本差异计算（compare_packages）

def compare_packages(old, new): def normalize(d): return {k.replace("-", "_").lower(): v for k, v in d.items()} old, new = normalize(old), normalize(new) added = [new[k] for k in new if k not in old] upgraded = [new[k] for k in new if k in old and new[k].version != old[k].version] removed = [old[k] for k in old if k not in new] ... if upgraded: output += "\nUpgraded packages:\n" + "".join(f" * {p.name} {old[p.name].version} → {p.version} ({p.description})\n" for p in upgraded if p.name in old)

对比逻辑非常直白：包名先做-与_归一化（所以索引中的sqlite-bro与sqlite_bro会被视为同一包），然后：

• 新索引有、旧索引没有 → "New packages"；
• 两边都有但版本号不同 → "Upgraded packages"，输出格式正是包名 旧版本 → 新版本 (描述)，与本文开头引用的原文档逐字一致；
• 旧索引有、新索引没有 → "Removed packages"；
• 完全一致则输出 "No differences found."。

（3）按版本号定位文件与写出文档（changelog_versions/write_changelog）

def changelog_versions(searchdir, flavor="", architecture=64): pattern = re.compile(rf"WinPython{re.escape(flavor)}-{architecture}bit-(.+)\.(?:txt|md)$") ... found.append((version.parse(match.group(1)), match.group(1), name))

changelog_versions用正则WinPythonZero-64bit-(.+)\.(txt|md)这类模式扫描changelogs/目录，把所有历史版本解析为 PEP 440 版本对象；find_previous_version找出目标版本之前最近的一个版本；write_changelog则将对比结果写入形如WinPythonZero-64bit-3.6.1.0_History.md的_History文件——与本次关联文档的命名完全对应。值得留意的是，wppm/diff.py 的注释专门提到：文件名是版本的唯一来源，且解析使用 PEP 440，因此3.14.7.1b1这类带发布级别（b1）的版本也能被正确排序，不会像早期按纯数字点分解析那样被静默丢弃。

命令行入口：wppm -diff与--write-changelog

wppm/wppm.py 中注册了-diff参数：

-diff INDEX1 INDEX2: compare two package indexes, whichever two you choose wppm -diff WinPythonslim-64bit-3.13.5.0.md WinPythonslim-64bit-3.14.7.0.md

任何两个索引文件（不要求连续版本、可以是不同 flavor）都可以直接对比，wppm.py收到-diff后调用diff.compare_files(*args.diff)并打印结果。若要生成正式的_History文档，则使用python -m wppm.diff --write-changelog <version2> <version1> [searchdir] [flavor] [architecture] [basedir]命令，例如：

python -m wppm.diff --write-changelog 3.6.1.0 3.6.0.2 changelogs Zero 64

它会自动定位两份索引、计算差异并写入changelogs/WinPythonZero-64bit-3.6.1.0_History.md。

一个易被忽略的工程细节：升级箭头与 UTF-8 编码

wppm/diff.py 和 wppm/wppm.py 中反复出现同一段代码：

if hasattr(sys.stdout, "reconfigure"): sys.stdout.reconfigure(encoding="utf-8", errors="replace")

源码注释给出了原因：每条升级记录都写成1.2.3 → 1.2.4形式，而 Windows 控制台默认编码是 cp1252，如果不强制 UTF-8，那个→箭头会被替换成?，导致"对比两个版本"变成一场回溯（traceback），整个页面的主题（升级箭头）都被破坏。这个细节体现了该工具在 Windows 平台下对输出编码的刻意处理，也是复现生成流程时最容易踩的坑。

延伸阅读：如何在当前仓库中继续挖掘

如果你希望继续深入研究这份历史记录及背后的工具链，可以在仓库中找到以下一手材料：

• 相邻版本的变更记录：同系列历史文档集中在 changelogs 目录，例如 WinPythonZero-3.6.0.0_History.md、WinPythonZero-3.6.0.1_History.md，可串联出 3.6 时代 Zero 分支的完整演进轨迹；
• 完整包索引快照：WinPythonZero-3.6.1.0.md 列出了本次升级后的全部 17 个 Python 包与空 Tools 分区，是核对"哪些包本次未变、哪些是更早版本引入"的权威依据；
• 对比引擎源码：wppm/diff.py 中的compare_packages、changelog_versions、find_previous_version、write_changelog四函数即可讲清整个生成链路；
• 命令入口：wppm/wppm.py 中的-diff参数定义，以及 wppm/diff.py 底部print_usage()输出的完整用法说明（包括--section、--pairs等细粒度对比模式）；
• 当前构建体系对照：winpython_builds.toml 展示了如今仓库实际构建的 flavor（dot/slim/free 等）与[pythons."3XX"]版本矩阵，可作为理解"Zero 已退出构建、其历史沉淀于 changelogs"这一现状的背景参照。

综上，WinPythonZero 3.6.1.0 的升级记录虽然只包含 7 个包的版本变化，但背后串联的是"极简发行版构成设计 + 版本索引快照 + 自动化差异对比"一整套可复现的发布工程流程——这份_History文档本身就是工具链自动运转的产物。

• 开发工具
• 构建工具
• CLI
• 包管理器