企业官网建设流程全解析

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

本文以 WinPython 官方仓库 changelogs 目录中的WinPythondot-32bit-3.7.7.1.md包清单为核心，系统解读 WinPython 历史精简发行版3.7.7.1dot（32 位）的精确包构成、自上一版本以来的变更明细，并结合当前仓库源码揭示这份 Markdown 清单的自动生成机制、dot 风味（flavor）在构建配置中的定义方式，以及读者如何用现有工具链复现同类构建、如何用wppm -diff自行比较任意两个发行版的包清单。读完本文，你将能读懂任何一份 WinPython changelog 清单，并理解清单背后"一个 Python 小版本 × 多个风味"的构建矩阵。

发行版背景：dot 风味是什么

WinPython 是为 Windows 平台打造的可移植 Python 发行版。同一 Python 小版本可以存在多种风味（flavor），每种风味对应一套不同的预装包策略。当前仓库根目录的 winpython_builds.toml 就集中定义了dot、dotf、slim、slimf、whl等风味，其中：

[flavors.dot] requirements = "dot_requirements.txt" source_dirs = "packages.win-amd64" toolsdirs = "bdTools\\Tools.dot"

可见 dot 风味使用仓库根目录下的 dot_requirements.txt 作为主要需求文件，并配套独立的 Tools 目录Tools.dot。该需求文件的当前内容为：

# the essential sqlite_bro setuptools wheel build ##msvc_runtime # end of requirements.txt

从源码结构看，dot 的定位是携带最精简 essentials 的最小可用发行版：一个可直接运行的 Python 解释器，加上打包分发工具（setuptools、wheel、build）和一个图形化 SQLite 客户端（sqlite_bro）。与之相对的slim风味则读取 requirements_slim.txt，预装包更多；dotf/slimf中的f对应 free-threaded（自由线程）解释器场景。所有风味共享仓库根目录的 mandatory_requirements.txt（内容为pip、setuptools、wppm）与 constraints.txt 作为公共约束。

3.7.7.1dot是这一风味机制在 2020 年的落地版本：32 位、基于 Python 3.7.7。需要说明的是，当前仓库的 winpython_builds.toml 仅列出313、314、315三个 Python 小版本的构建目标，3.7 已不在构建列表内，因此本文对 3.7.7.1dot 的讨论属于对历史发行版清单的解读，而构建机制本身延续至今。

3.7.7.1dot 完整包清单

changelogs/WinPythondot-32bit-3.7.7.1.md 以标准"名称 | 版本 | 描述"表格记录了该发行版包含的包。整个发行版只包含 6 个 Python 包，Tools（外部工具）一节为空：

逐包解读如下：

• Python 3.7.7：发行版核心，Python 解释器及标准库。dot 风味不预装 NumPy 等科学计算栈，只保证解释器本身开箱可用。
• pip 20.1：PyPA 官方推荐的包安装工具，负责后续一切包的增删。WinPython 官方同样推荐用 pip 管理包，WPPM 只是辅助工具。
• setuptools 46.4.0：Python 包的构建、安装、升级与卸载基础设施，绝大多数第三方包安装时的依赖。
• sqlite_bro 0.9.1：这个版本新增的亮点——一个仅用单个 Python 文件实现的图形化 SQLite 客户端，对应 dot_requirements.txt 中唯一一个非打包工具类的预装包。
• wheel 0.34.2：wheel 内置包格式的标准化工具，保证发行版内包可以被快速安装。
• winpython 2.4.20200425：WinPython 发行工具本身，内含 WPPM（WinPython Package Manager）。其版本号2.4.20200425中的日期戳可推断该发行版发布于 2020 年 4 月 25 日前后。

自 3.7.7.0dot 以来的变更明细

同一目录下的 changelogs/WinPythondot-32bit-3.7.7.1_History.md 记录了相对上一版3.7.7.0dot的全部变更，变更只发生在 Python 包一节，Tools 与 WheelHouse 无变动：

新增包：

升级包：

这份 History 文件本身也是构建工具链的产物（生成机制见下节），其价值在于让升级者一眼看清"哪些包动了"，而主清单文件则提供发行版最终状态的完整快照。两者配合使用：先看 History 了解变更，再看主清单确认最终版本。

包清单文件是如何自动生成的

这份清单并非手工维护，而是构建流程的自动产物。其核心生成逻辑位于 wppm/wppm.py 的Distribution类：

• get_package_index_data()（wppm/wppm.py）收集四类数据：发行版身份（名称、版本、Python 版本、位数、release level）、Tools 列表、已安装 Python 包列表（通过 pip 的完整列表导出）、WheelHouse 包列表（读取发行版wheelhouse/included.wheels目录）。
• generate_package_index_markdown()（wppm/wppm.py）把上述数据渲染成 Markdown：先输出## WinPython {版本}标题行，再依次渲染Tools、Python packages、WheelHouse packages三节。
• render_markdown_for_list()（wppm/wppm.py）生成标准的"Name | Version | Description"表格，并按包名排序。

在构建流程中，winpython/build_winpython.py 的 Step 7（"generate changelog"）负责把这份 Markdown 写入仓库的 changelogs 目录，文件命名遵循WinPython{flavor}-{arch}bit-{changelog_version}.md（winpython/build_winpython.py），例如本文主角WinPythondot-32bit-3.7.7.1.md，其中dot即风味名、32bit即架构、3.7.7.1是合并了 Python 版本号与 release 的发行版版本号。同一命令还会调用 wppm/diff.py 的compare_package_indexes()与上一版本清单做对比，产出_History.md文件。

值得注意的一个版本命名细节：winpyver的拼接规则为winpyver2 + flavor + release_level（winpython/build_winpython.py），因此一个 beta 版如3.7.7.1dotb1与正式版3.7.7.1dot共享同一个winpyver2，把 release level 放进文件名才能避免 beta 的包列表覆盖正式版的文件——这解释了为什么历史 changelogs 中会出现带b1后缀的文件名。

如何在当前工具链中复现 dot 风味构建

当前仓库采用"一个 TOML 配置 + 一个元脚本"的方式驱动构建。入口脚本是仓库根目录的 build_winpython_meta.py，Windows 下通过 generate_a_winpython_distropy_meta.bat 调用（该 bat 将参数原样透传给元脚本）。典型命令（见 winpython_builds.toml 头部注释）：

# 只构建 315 的 slim 风味 generate_a_winpython_distropy_meta.bat winpython_builds.toml 315:slim # 构建 315 的全部风味（dot、dotf、slim、slimf） generate_a_winpython_distropy_meta.bat winpython_builds.toml 315 # 构建配置里列出的所有 Python 小版本的全部风味 generate_a_winpython_distropy_meta.bat winpython_builds.toml # 只打印将执行的构建命令，不真正执行 generate_a_winpython_distropy_meta.bat winpython_builds.toml 315 --dry-run

选择器语法为目标:风味，目标与风味均可省略（如315或:slim），由 build_winpython_meta.py 的select_builds()解析。其底层逻辑是：每个(python, flavor)组合派生出一条构建命令，requirements、source_dirs、wheelhousereq相对bd{python}基准目录，toolsdirs相对构建根目录（见 build_winpython_meta.py 与配置文件头部注释）；每个 Python 小版本还可以通过[pythons."3XX".overrides.<flavor>]单独覆盖某个风味的配置。

run_build()（build_winpython_meta.py）最终调用python -m winpython.build_winpython，可传入的关键参数及含义（与 winpython/build_winpython.py 的参数定义一一对应）：

构建前置条件：运行工具链的 Python 需为 3.11 或更高（build_winpython_meta.py 明确注释 "Local builds are made with Python 3.11 or later"），安装器可以是 7-Zip 或完全不要（仅 zip 打包）。构建日志写入WinPython_build_logs目录，文件名带时间戳（winpython/build_winpython.py）。

用 wppm 自行比较任意两个发行版清单

changelogs 目录归档了 WinPython 各版本、各风味的全部包清单文件。借助 WPPM 的-diff子命令，可以脱离"相邻版本"的限制，任意挑选两份清单进行对比（用法见 wppm/wppm.py）：

wppm -diff WinPythonslim-64bit-3.13.5.0.md WinPythonslim-64bit-3.14.7.0.md

该命令读取两个 Markdown 索引文件并输出新增/升级/降级/移除包列表，方向可任意、版本不必相邻——例如想复现本文"3.7.7.0dot → 3.7.7.1dot"式的变更分析，只需对changelogs/目录下对应的两份 dot 清单执行同样操作。这正好弥补了_History.md只对比紧邻版本的局限：归档只保留各版本清单快照，而差异分析能力完全交给用户按需调用。

小结

一份看似简单的包清单表格，背后串联了 WinPython 仓库的多条主线：dot 风味通过 winpython_builds.toml 与 dot_requirements.txt 定义包集合；构建工具链在 winpython/build_winpython.py 的 Step 7 用 wppm/wppm.py 的Distribution类自动生成清单与 History；构建矩阵由 build_winpython_meta.py 从 TOML 展开为具体命令。对读者而言，掌握wppm -diff、generate_a_winpython_distropy_meta.bat ... --dry-run等既有工具，就能把任何历史版本（包括 3.7.7.1dot）的构成差异与复现路径握在自己手中。

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