企业官网建设流程全解析

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

本篇指南以仓库内的官方变更日志 changelogs/WinPythondot-32bit-3.9.0.2_History.md 为主体，逐条解读 WinPython 32 位dot（最小化）发行版从3.9.0.1dot升级到3.9.0.2dot时的四个核心包变更，并结合仓库源码说明dotflavor 的定位、上游依赖清单的构成、变更日志的生成机制以及可复现的验证方法。读完本文，你将能看懂 WinPython 版本历史文档背后的工程含义，并能在自己的构建环境中核对与复现同样的版本组合。

版本定位：3.9.0.2dot 是什么

变更日志标题WinPython-32bit 3.9.0.2dot遵循 WinPython 一贯的版本命名规律，可拆解为：

• Python 版本：3.9.x 系列；
• 发行版架构：32 位（32bit）；
• 构建号：2；
• flavor（口味/变体）：dot，即最小化发行版。

这一拼装规则在源码中可以直接印证。在 winpython/make.py 中，WinPythonDistributionBuilder通过以下属性拼出完整的版本字符串：

@property def winpython_version_name(self) -> str: """Returns the full WinPython version string.""" return f"{self.python_full_version}.{self.build_number}{self.flavor}{self.release_level}"

即{Python 完整版本}.{构建号}{flavor}{发布级别}，与3.9.0.2dot的结构完全吻合。

而dot这一 flavor 的含义，记录在构建清单 winpython_builds.toml 中：

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

也就是说，dot变体使用独立的依赖清单dot_requirements.txt、从packages.win-amd64目录读取 wheel 包，并将bdTools\Tools.dot作为随发行版分发的开发工具目录。变更日志中“since version 3.9.0.1dot”的字样，说明这是同一个 flavor 系列内的增量升级记录。

本次升级的四个核心包

日志正文将变更归入Upgraded packages一节，共涉及四个包。它们分别是发行版自举（bootstrap）与运行所必需的基础组件：

下面逐包说明其在本发行版中的角色与仓库依据。

msvc_runtime：运行时的地基

msvc_runtime负责把 Microsoft Visual C++ 运行时 DLL 安装进 Python 环境的sys.prefix与Scripts目录。对 Windows 平台上的 Python 发行版而言，这是关键一环：大量科学计算与编译型扩展模块依赖 VC++ 运行时，缺了它会出现DLL load failed一类问题。日志中版本号从14.27.29016升到14.27.29016.1，属于同一运行时主版本内的补丁级修订。

在依赖清单 dot_requirements.txt 中可以看到该包的痕迹：

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

注意##msvc_runtime行——#注释掉的是该包条目，注释语法与 wppm/utils.py 中“将 pip 依赖清单拆分为条目与注释行”的处理方式相对应。这从侧面说明：dotflavor 的“essential”包集合在不同时期做过取舍，msvc_runtime曾在清单中占据一席之地，后来在较新版本中被注释停用。日志中的升级记录正是该包参与发行版组装时的历史快照。

pip：包管理的入口

pip是任何 Python 发行版的安装入口，日志中它的版本从20.2.2升到20.2.4（2020 年 10 月前后的 PyPA 发布线）。在构建体系中，pip 不仅服务于终端用户，也是构建工具链的一部分：winpython/build_winpython.py 中的pip_install函数以python -m pip install为核心，携带-r（需求清单）、-c（约束文件）、--no-index与--find-links（本地 wheel 源）等参数完成发行版组装：

def pip_install(python_exe: Path, req_file: str, constraints: str, find_links: str, label: str, options:[]): if req_file and Path(req_file).exists(): cmd = [ str(python_exe), "-m", "pip", "install", "-r", req_file, "-c", constraints, "--no-index", f"--find-links={find_links}", "--upgrade", "--no-warn-script-location" ] ...

也就是说，升级 pip 不只是给最终用户换工具，还会影响后续每次构建时pip install解析依赖的行为，属于发行版“地基”级别的变更。

setuptools：构建与打包的支撑

setuptools从49.6.0升到50.3.2，承担“下载、构建、安装、升级、卸载 Python 包”的元数据与构建能力。它是两个依赖清单中的共同成员：

• mandatory_requirements.txt（发行版强制依赖）：包含pip、setuptools、wppm；
• dot_requirements.txt（dot flavor 必需依赖）：同样列出setuptools，并附带wheel、build、sqlite_bro。

可见无论哪种 flavor，setuptools都是必装项，本次升级属于常规跟进上游版本。

winpython：发行版自带工具包（含 WPPM）

winpython包（即“WinPython distribution tools, including WPPM”）从3.0.20200808升到3.0.20201028。WPPM（WinPython Package Manager）负责发行版的包管理、版本检查与变更日志生成等任务。该包在仓库中对应的现代实现位于 wppm/ 目录，其版本号已演进到 wppm/init.py 中的__version__ = '17.13.20260913'——日志中的3.0.20201028是 2020 年 10 月的历史版本，两者对比可以清晰看到这套工具链长期持续的迭代。

变更日志的生成机制：源码里藏着答案

这份_History.md的表格格式（Name | Version | Description三列）并非手写，而是由 WPPM 自动生成。在 wppm/wppm.py 中，Distribution.render_markdown_for_list正是按同样的列结构输出 Markdown：

def render_markdown_for_list(self, title, items): """Generates a Markdown section; name, url, version, summary""" md = f"### {title}\n\n" md += "Name | Version | Description\n" md += "-----|---------|------------\n" for name, url, version, summary in sorted(items, key=lambda p: (p[0].lower(), p[2])): md += f"{name} | {version} | {summary}\n" md += "\n" return md

配合get_package_index_data（wppm/wppm.py），WPPM 会枚举发行版内已安装的包（get_installed_packages）、随附工具（utils.get_installed_tools）与 wheelhouse 内的 wheel（wh.list_packages_with_metadata），拼出包索引数据后再渲染为 Markdown。因此，changelogs/下各版本的_History.md可以理解为“发行版构建时的包快照 + 版本间 diff”的机器可读记录，Upgraded packages一节即由旧快照（3.9.0.1dot）与新快照（3.9.0.2dot）比对而来。

这也解释了为什么日志里只列“升级”不列“新增/移除”——表格形式天然适合做包级 diff，是 WPPM 版本管理流水线的一部分。

在本地核对与复现这些版本组合

如果你想在自己的环境中验证3.9.0.2dot的包组合，或复现一次类似的构建，可以参考以下路径。

核对已安装版本

对已安装的发行版，直接查询即可：

python -m pip list :: 或 python -m pip show pip setuptools msvc_runtime winpython

对比输出中这四个包的版本号是否与日志一致，即可确认发行版是否处于3.9.0.2dot状态。

理解构建时的版本约束

构建过程中，包版本并非随意浮动，而是受两重约束：

1. 依赖清单：如 dot_requirements.txt（dot flavor）与 mandatory_requirements.txt（强制项pip、setuptools、wppm）；
2. 约束文件 constraints.txt：对全量包给出>=版本下限，例如setuptools>=80.9.0、pip相关条目与wppm>=17.2.20250823等（注意当前约束文件反映的是仓库最新构建线，数值远高于 2020 年的历史快照，对照阅读时需注意时间线）。

在 winpython_builds.toml 的注释中，给出了本地构建的典型入口：

generate_a_winpython_distropy_meta.bat winpython_builds.toml 315:slim generate_a_winpython_distropy_meta.bat winpython_builds.toml 315 generate_a_winpython_distropy_meta.bat winpython_builds.toml :: ... --dry-run 只打印构建命令而不实际执行

其中315:slim表示构建3.15的slimflavor；对dotflavor，则对应[flavors.dot]一节配置（依赖清单、wheel 源目录packages.win-amd64、工具目录bdTools\Tools.dot）。构建底层由 winpython/make.py 的WinPythonDistributionBuilder驱动：先从 wheel 目录中定位python-*.zip基础归档（_get_python_zip_file），解压出 Python 环境、拷贝启动器与工具（_copy_essential_files），最后写入scripts/env.ini（_create_env_config，内含WINPYVER、WINPYFLAVOR、WINPYARCH等标识）。构建完成后，包版本快照便可通过 WPPM 生成类似本文所解读的_History.md变更日志。

小结：一份薄日志背后的完整工程链路

WinPythondot-32bit-3.9.0.2_History.md虽然只有四条升级记录，但它不是孤立的发布说明，而是 WinPython 构建体系的“冰山一角”：

• flavor 语义：dot对应 winpython_builds.toml 中的独立依赖清单与工具目录配置；
• 包角色：msvc_runtime（运行时）、pip/setuptools（包管理与构建地基）、winpython（含 WPPM 的发行版工具）共同构成发行版自举的最小闭环；
• 生成机制：日志表格由 WPPM（wppm/wppm.py）的包索引与 Markdown 渲染逻辑自动产出；
• 可复现性：通过依赖清单、约束文件与 winpython/make.py 的构建流程，任何基于本仓库的构建都能追溯到日志所列版本的确切来源。

对于希望深入理解 WinPython 发布流程、或想读懂其历史版本档案的开发者，这条从“变更日志”到“构建配置”再到“源码实现”的阅读路径，是最直接有效的切入点。

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