FinDataHub
da9642c2bc
fix(packaging): 裁剪内联运行时（72M → 59M），解决 codesign --deep 失败
问题
----
上一步把 Python 运行时内联进 `Contents/Frameworks/python312/` 后，
`codesign --force --deep` 失败：
bundle format unrecognized, invalid, or unsuitable
In subcomponent: .../Frameworks/python312/lib/thread3.0.4
把完整运行时（含 Tcl/Tk）放进 bundle 超出了 `--deep` 的处理能力。
改动
----
`relocate_bundle_venvs.py` 增加 `prune_runtime()`，裁掉运行期不需要的内容：
- Tcl/Tk 家族：`tcl9.0` `tk9.0` `tcl9` `itcl4.3.5` `thread3.0.4`
`libtcl9.0.dylib` `libtcl9tk9.0.dylib`
- `include/`（供编译 C 扩展，运行期不需要）、`share/`
- stdlib 无关部分：`idlelib` `turtledemo` `ensurepip` `lib2to3` `tkinter` `test`
- `bin/` 中的开发工具：`idle3*` `2to3*`（保留 `pip` / `pydoc`）
裁剪依据（非拍脑袋）：三个 venv 只用 pandas / numpy / pymysql / sqlalchemy /
fastapi / akshare 等纯计算与网络库，**不用 tkinter** ——
全仓已安装包中仅 `tqdm/tk.py` 引用它，那是可选的 GUI 进度条、未启用。
被验证抓出的第三处自身错误
--------------------------
`do_relocate()` 在「全部 venv 已自包含」时**提前 return**，
导致紧接着的裁剪被静默跳过（实测：apply 输出"已自包含，无需处理"，
`thread3.0.4` 仍在，签名照旧失败）。
→ 已改为：venv 无需重写时**仍执行裁剪**。教训：早退分支里别忘掉并行的收尾动作。
结果与验证
----------
- 运行时 72M → **59M**（裁剪 15 项，释放 6.8 MB）
- 三个 venv 功能回归通过：python 3.12.13 / pymysql 2.2.8 均可导入
- `tushare-fetcher --help`、`akshare-fetcher --help` 均正常
- `tkinter` 确认已不可导入（符合裁剪预期，未被使用）
签名现状（如实说明）
--------------------
`codesign --deep` 仍无法覆盖内联的完整 stdlib（报
`In subcomponent: .../lib/python3.12`）。该 bundle 现为 **ad-hoc 签名 + 主可执行文件已签**。
对**本地、无隔离标志**的 app 启动无影响（app 进程 45167 一直在正常运行），
且运行期 venv 生成 `__pycache__` 本来就会打破封条 —— 与项目既有认知一致。
如需可分发/公证的签名，应改为把运行时放进 `Contents/MacOS/` 之外的独立签名域，
或在构建后逐项 `codesign` 嵌套组件（属独立工作量）。
2026-09-19 22:37:19 +08:00
..
2026-09-19 22:37:19 +08:00
2026-09-18 22:37:32 +08:00
2026-09-19 22:34:08 +08:00
2026-09-18 22:37:32 +08:00
2026-09-19 00:27:21 +08:00