企业官网建设流程全解析

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

WinPythonslim-64bit-3.14.6.0.md 是 WinPython 构建体系为某一次具体发布（3.14.6.0slim b2）生成的“发行清单”：它逐条列出了该发行版捆绑的 2 个工具、532 个 Python 包及各自版本，并可对照仓库中的构建配置、依赖清单与锁定文件，完整还原这份清单是如何被筛选、安装和钉住（lock）的。读完本文，你能理解 WinPython 的“flavor（风味）+ 构建周期（cycle）”模型、slim 风味相对其他风味的取舍逻辑，并掌握如何仅凭仓库内的锁定文件复现、校验乃至比对任意一次发行版的软件包集合。

一、这份文档在仓库中的定位：一次发布的“锁快照”

在 WinPython 仓库里，changelogs/ 目录下的每个WinPython<flavor>-<arch>bit-<version>.md文件都对应一次真实发布，结构固定为三段：

1. Tools：发行版捆绑的系统级工具（本版本为 2 项）；
2. Python packages：发行版内全部 Python 包（本版本为 532 项，含名称、版本、一句话描述）；
3. WheelHouse packages：随发行版附带、可用 wppm 离线安装的 WheelHouse 包（本版本为空）。

版本号3.14.6.0slim b2各段含义可以从仓库源码得到印证：

• 四段版本 = Python 版本 + WinPython 发布序号 + 构建级别。测试文件 tests/test_changelog_files.py 中parse_changelog_name("WinPythonslim-64bit-3.15.0.5b1.md")被断言解析为("slim", 64, "3.15.0.5b1")，说明文件名本身编码了风味、位数与完整版本号；
• b2 是构建级别（release level）。cycles/2026_04.toml 头部注释说明：“this cycle releases as 2026-04b1 and a respin is a release_level bump rather than a new tag to invent”，即同一周期内重新出包只升级 b 号而不新造标签。本清单头部所写的 “v3.14.6.0slim b2” 正是该周期（2026-03）内 3.14.6.0 这个 Python 补丁级的第 2 次构建；
• 同一 Python 级在仓库中可能累积多个构建的锁文件。winpython/portable/cycle_2026_03/ 目录下同时存在pylock.64-3_14_6_0slimb1.toml与 pylock.64-3_14_6_0slimb2.toml，与 changelog 中 “b2” 的记述一一对应。

因此这份 changelog 不是手写说明，而是构建管线产出的元数据之一，与锁文件、哈希清单共同构成一次发布的完整凭据。

二、Tools：Python 3.14.6 与唯一捆绑工具 Pandoc 3.1.9

清单 Tools 表（原文照录）：

“slim 只带 Pandoc”并非随意裁剪，而是由构建配置决定的：

• 在 winpython_builds.toml 中，slim 风味的定义是：

  [flavors.slim] requirements = "requirements_slim.txt" source_dirs = "packages.win-amd64" toolsdirs = "bdTools\\tools64_pandoc_alone"

  其中tools64_pandoc_alone这个工具目录名直接表明：该风味只取 Pandoc 单独一份工具集；而dot风味取的是更完整的bdTools\Tools.dot。

• cycles/2026_03.toml（本清单所属构建周期）中的风味矩阵同样区分了这一点：slim的PANDOC = "1"、WINPYARCHDET = "64"、产物格式formats = { zip = false, "7z" = true, exe = true }；dot则PANDOC = "0"。

• 周期文件把 Pandoc 的来源钉到具体制品并附 SHA-256：pandoc-3.1.9-windows-x86_64.zip，sha25611eb6dbe5286c9e5edb0cca4412e7d99ec6578ec04158b0b7fe11f7fd96688e5，与清单中的 3.1.9 版本吻合。

• Python 解释器本身来自 python-build-standalone 的发行 tarball（周期文件中给出cpython-3.14…x86_64-pc-windows-msvc-install_only_stripped.tar.gz及对应 sha）。需要注意：仓库当前的 cycles/2026_03.toml 中[pythons."3.14"]已指向周期后续使用的 3.14.7 tarball（该文件随周期推进被更新），而 cycle_2026_03 目录中仍保留着本清单对应的3_14_6_0b1/b2 锁定文件，二者分别对应周期内不同构建批次。

三、532 个 Python 包：按领域速览（版本均取自清单原文）

清单的 Python packages 表共 532 项，逐项带 PyPI 描述。为便于检索，下面按领域摘录代表性条目（名称与版本均与 changelogs/WinPythonslim-64bit-3.14.6.0.md 原文一致），完整 532 项请查阅该文档。

3.1 构建工具链的“必选三件套”

mandatory_requirements.txt 只有三行（注释标明 Wheel 不在其中）：

pip setuptools wppm

对应清单中的版本：pip 26.1.2、setuptools 82.0.1、wppm 17.6.20260621（WinPython Package Management）。build_winpython_meta.py 中declared_file(build, "mandatory_requirements", here / "mandatory_requirements.txt")保证每个构建默认使用这份与 toml 同目录的必选清单，缺失会直接抛FileNotFoundError而不是静默丢包。

3.2 数值与科学计算

3.3 数据分析、地理与数据库

3.4 机器学习与 LLM/AI 生态

3.5 交互式环境与 IDE

3.6 Web 与网络

3.7 开发工具

pytest 9.0.3、mypy 2.1.0、ruff 0.15.20、black 26.5.1、pylint 4.0.5、flake8 7.1.1、isort 7.0.0、hypothesis 6.155.2、twine 6.2.0、build 1.4.2、flit 3.12.0、hatchling 1.30.1、pipdeptree 3.1.0、wheel 0.47.0、debugpy 1.8.20等。

3.8 WheelHouse 为空意味着什么

清单第三段WheelHouse packages 表为空。这符合从源码结构可推断的分工：把 wheel 随发行版离线携带是whl风味的职责（winpython_builds.toml 中wheelhousereq = "requirements_whl.txt"仅配置在该风味下，且该文件头部注明 “Not built at the moment: no python below lists it”）。slim 风味默认pip联网解析安装（见下节--only-binary等参数），不附带离线仓库，因此该段为空属预期行为。

四、清单从哪来：slim 风味的构建管线

4.1 (python, flavor) 模型：winpython_builds.toml

winpython_builds.toml 头部的注释给出了整个管线的核心抽象：

A build is a (python, flavor) pair. Everything else is derived: basedir = {root_dir_for_builds}\bd{python} requirements = {basedir}\{flavor requirements} source_dirs = {basedir}\{flavor source_dirs} wheelhousereq = {basedir}\{flavor wheelhousereq} toolsdirs = {root_dir_for_builds}\{flavor toolsdirs}

对本次清单涉及的 3.14 系列：

[pythons."314"] python_target_release = "3147" release = "1" my_release_level = "b1" builds = ["dot", "dotf", "slim", "slimf"]

即 3.14 这一 minor 下要出 4 个风味：dot（完整科学栈）、dotf（dot + free-threaded 解释器）、slim（精简栈）、slimf（slim + free-threaded，pythons."314".overrides.slimf 还为它单独设了only_binary = false，注释说明原因是 tornado 当时只提供 cp39-abi3 wheel，free-threaded 解释器无法匹配，必须允许 sdist 兜底）。

build_winpython_meta.py 的expand_builds()会把上表展开为具体构建：[defaults]提供root_dir_for_builds、find_links = "C:\\Winp\\packages.srcreq"（本地 wheelhouse 索引）、arch = "64"等公共值；[pythons."3XX".overrides.<flavor>]可以为某个 Python 单独覆盖某个风味的条目。命令行可按314、314:slim或:slim选择构建（select_builds()的三种规格），加--dry-run只打印命令。

4.2 构建命令的实际形态

run_build()最终拼接出交给winpython.build_winpython模块的完整命令，其中与 slim 相关的参数包括：

python -m winpython.build_winpython --buildenv <buildenv> --python-target 314 \ --release <release> --release-level <level> --winpydirbase <WPy64-314…> \ --flavor slim --source_dirs <basedir>\packages.win-amd64 \ --tools_dirs <root>\bdTools\tools64_pandoc_alone \ --log-dir WinPython_build_logs --mandatory-req mandatory_requirements.txt \ --requirements <basedir>\requirements_slim.txt --constraints constraints.txt \ --find-links C:\Winp\packages.srcreq --wheelhousereq "" \ --bytecode pip --only-binary yes --create-installer None

参数语义（见 build_winpython_meta.py 中的取值逻辑）：

• --bytecode：pip（默认，随发行版预编译字节码）|none|parallel|parallel-N；
• --only-binary：由only_binary键推导，默认yes（仅装 wheel）；
• --create-installer：本 toml 中默认None（只出 zip，不打安装器），[pythons."314".overrides.slim]预留了改为".7z-mx7"的注释开关。

入口脚本 generate_a_winpython_distropy_meta.bat 只是薄封装：

rem <toml> [315 | 315:slim ...] [--dry-run] call "C:\WinPdev\WPy64-31190\python-3.11.9.amd64\python.exe" %~dp0\build_winpython_meta.py %*

即generate_a_winpython_distropy_meta.bat winpython_builds.toml 314:slim就是本地构建本清单对应发行版的最小命令（--dry-run可预览）。注意该工具链要求 Python ≥ 3.11 运行（README.rst 与 build_winpython_meta.py 头部注释一致）。

4.3 requirements_slim.txt：532 项清单的“种子”

532 个包并非手写，而是由 requirements_slim.txt 这 112 个直接条目经依赖解析展开而来。文件头部自带审计信息：

# requirements_slim.txt, sorted, 2026-08-13 19:15:35 # 160 entries -> 112 kept, 48 already pulled in # 8 repeated, collapsed: brotli, openai, pympler, pytest, python-barcode, pywavelets, sympy, xlsxwriter

文件下半部是一大段# 已随上方条目引入的注释（如#numpy # <- baresql, clarabel, cvxpy, dask, datashader, ...），把“谁拉动了谁”的依赖关系显式记录下来——这正是 changelog 中 532 项远多于 112 项的直接原因。

文件末尾还保留了发布间的人工取舍日志，可视为 slim 风味演进的“变更说明”：

# 2026-07-12 # switch geopandas for opencv # 2026-08-03: # astropy, django, distributed removed (place) # pymongo removed # 2027-08-07 # remove geopandas (and so pyogrio, pyproj) # 2026-08-08 # pydub unmaintained

对照 3.14.6.0slim b2 清单可以看到取舍的时间边界：geopandas 1.1.3、pymongo 4.15.3、astropy 7.2.0、django 6.0.4仍在该清单中（它们是在后续周期才被移出），而带安全考量被排除的httpie（“outdated and vulnerable”）与mistralai（“get security problematic crpytography”）则没有出现在清单里。这说明 changelog 与 requirements 文件是同一构建决策在不同时点的投影。

五、元数据四件套与锁文件：一次发布如何被“钉住”

tests/test_changelog_files.py 的模块 docstring 精确描述了每次构建腿（leg）向仓库贡献的四个元数据文件，其中三个进 changelogs/：

WinPythonslim-64bit-3.15.0.5b1.md # 发行清单（本文主角的同类文件） pylock.64-3_15_0_5slimb1.toml # 锁定文件（pip lock 格式） requir.64-3_15_0_5slimb1.txt # 带哈希的可安装 requirements hashes_3.15.0.5slimb1.md # 本次构建二进制描述，不进 changelogs/

并明确“不写_History.md伴生文件”：跨版本比较不由管线自动完成，而是留给读者用wppm -diff a.md b.md对两份自选清单做比较。tests/test_diff_versions.py 则从另一侧固定了行为：find_previous_version在同风味内找上一版本，且 “dot and slim ship different package sets; a cross-flavor diff is noise”——跨风味比较没有意义。

对本清单对应的构建，这些工件在仓库中的落点为：

• winpython/portable/cycle_2026_03/pylock.64-3_14_6_0slimb1.toml 与 pylock.64-3_14_6_0slimb2.toml：lock-version = "1.0"、created-by = "pip"，逐包记录 wheel 文件名与 sha256；
• requir.64-3_14_6_0slimb1.txt/requir.64-3_14_6_0slimb2.txt：同一锁的“带哈希 requirements”形态，供pip install --require-hashes直接消费；
• 文件名规则由 srcreq_manifest.py 中的正则统一解释：pylock.64-<ver><flavor>(b<level>)?(_wheels)?.toml，其中 “一个周期会累积多个补丁级（3_14_6_0、3_14_7_0…）与多个构建级别（b0、b1…）的锁文件，只有每风味最新者才算当前状态”。

srcreq_manifest.py 还负责治理本地 wheelhouse（构建时pip install --no-index --find-links=...的索引目录）：它把每个文件按锁文件与需求文件归类为used（当前锁在用）、pending（比锁更新、为下个周期预置）、superseded（项目仍在用但版本被取代）、dead（无处引用）四类，并强调“删除是安全的，因为锁文件都在 git 里，任何历史发行版都可以用pip download --require-hashes -r <its pylock>重新取回”。

六、复现与消费这份清单

仓库本身是wppm包 + 构建工具链，不是发行版实体（README.rst 明确说明）。基于仓库内文件可执行的消费方式：

1. 只装这一发行版的 wheels（离线复现）：用与清单配套的带哈希 requirements 文件（如 winpython/portable/cycle_2026_03/requir.64-3_14_6_0slimb2.txt）：

   python -m pip install --no-deps --require-hashes requir.64-3_14_6_0slimb2.txt

   README 推荐的正是这种--no-deps --require-hashes模式（其示例指向发布页同名的requir.*.txt），也可用 pip 支持后对应的pylock.*.toml。

2. 安装/升级包：README 建议以pip为首选方式增删包；wppm作为补充工具，用于浏览发行版内包、从随附 WheelHouse 安装或注册 WinPython（本次 slim 清单 WheelHouse 为空，故 wppm 的离线安装能力在该发行版上没有用武之地）。

3. 构建 wppm 本身：python -m pip install flit && python -m flit build（见 README.rst 与 pyproject.toml 中build-backend = "flit_core.buildapi"）。

4. 比对两次发布：对两份 changelog（或requir/pylock文件）执行wppm -diff a.md b.md，得到用户自选的两版本差异，而不是管线自动生成的历史。

七、小结

changelogs/WinPythonslim-64bit-3.14.6.0.md 表面是一份“包名-版本”清单，实际是 WinPython 构建管线在 2026-03 周期内314:slim构建腿（b2 级）的完整投影：

• 内容层：Python 3.14.6 + Pandoc 3.1.9 两个工具，532 个经requirements_slim.txt（112 直接条目 + 48 个传递依赖）解析出的包，必选三件套pip/setuptools/wppm，空 WheelHouse；
• 结构层：由 winpython_builds.toml 的(python, flavor)抽象与tools64_pandoc_alone等风味特定目录决定形态，由 build_winpython_meta.py 展开成带--flavor、--bytecode、--only-binary等参数的一体化构建命令；
• 凭据层：changelog.md + pylock.toml + requir.txt + hashes.md四件套配合 cycles/2026_03.toml 中的工具 sha256，使该发行版可被--require-hashes精确复现、可被srcreq_manifest.py治理、可被wppm -diff与任意另一份清单比对。

理解这套“清单-配置-锁文件”三层对应关系后，阅读仓库中任何一份WinPython*<version>.md发行清单，都能反推出它背后的构建参数与可复现路径。

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