Replace munki-pkg with swiftpkg for managed Python packaging
還沒有人認領這個 Issue。
- 主要語言
- Shell
- 星號
- 257
- 分支
- 29
- PR 合併指標
- 30 天內沒有已合併 PR
描述
Objective
Migrate this repository's managed Python installer packaging to codecarton/swiftpkg and retire the munki-pkg build dependency.
Current behavior
build_python_framework_pkgs.zsh downloads a pinned munki-pkg commit using MP_SHA, MP_BINDIR, and MP_ZIP. Its build_pkg() function generates recommended/build-info.json, stages preinstall-cleanup, invokes munkipkg, and moves the signed package into outputs/. Notarization and stapling run separately. Without an installer identity, the script skips package creation and still produces the framework ZIP.
Implementation scope
- Select and pin a published swiftpkg CLI release compatible with Apple Silicon build hosts; verify the downloaded artifact against a pinned SHA-256 and document prerequisites.
- Replace the munki-pkg download, temporary paths, and invocation with swiftpkg; propagate failures clearly.
- Validate compatibility of every generated build-info setting, especially
ownership,suppress_bundle_relocation,preserve_xattr,distribution_style, andsigning_info. Implement equivalent behavior for any unsupported settings. - Preserve the package identifier (
io.macadmins.python.recommended), version derivation, output filename/location, payload layout, permissions, symlinks, extended attributes, and preinstall cleanup behavior. - Preserve framework code signing and the existing installer signing/notarization/stapling sequence; avoid duplicate notarization.
- Ensure Python 3.11, 3.12, 3.13, and 3.14 workflows use the replacement and continue publishing expected artifacts; update workflows only where necessary.
- Update README build prerequisites and credits. Remove active munki-pkg dependencies and obsolete bootstrap references while retaining appropriate historical attribution.
Acceptance criteria
- Local and CI packaging use the pinned swiftpkg CLI with verified artifact integrity; no active build path downloads or executes munki-pkg.
- All generated build-info options have verified equivalent behavior, with any migration differences documented.
- On Apple Silicon, inspect a baseline munki-pkg package and replacement package to confirm equivalent receipts, version, install paths, payload, ownership/modes, symlinks, extended attributes, installer scripts, and non-relocation behavior.
- Signed packages pass signature checks, notarization, and stapling validation using the existing signing credentials.
- Clean-install and upgrade smoke tests on a disposable Apple Silicon Mac confirm preinstall cleanup, framework installation at
/Library/ManagedFrameworks/Python/Python3.framework, themanaged_python3symlink, and execution/imports of the managed runtime and bundled dependencies. - The no-installer-identity path continues producing the framework ZIP without requiring signing credentials.
- Each supported Python workflow builds and publishes the expected package artifact.
-
zsh -n build_python_framework_pkgs.zshpasses; any modified workflow YAML parses successfully. - README documents the replacement tool, pinned version/update procedure, and prerequisites.
Boundaries
This change replaces the package builder. It does not remove support for deploying the resulting installer through Munki, change Python/runtime dependencies, add the Swiftpkgr desktop app, or change the managed framework's installation contract.
貢獻指南
這個儲存庫沒有索引到貢獻指南
從這裡開始
- 先讀完整個 Issue,再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫,在一個分支上完成修改。
- 送出 Pull Request,並在描述裡引用這個 Issue 編號。
研究方向
從 build_python_framework_pkgs.zsh 開始,特別檢查 build_pkg()、munki-pkg bootstrap 變數,以及現有的 build-info.json 產生流程。接著檢查 Python 3.11–3.14 的 workflow 檔案和 README 中的先決條件。在 Apple Silicon 上比較 baseline package 和替換 package,並使用列出的 shell、簽署、notarization、smoke test 和 artifact 檢查來驗證是否完成。
由索引模型根據 Issue 內容生成。
評估
- 技術堆疊
- shell
- 領域
- build-system, ci-cd, tooling
- Issue 類型
- 重構
- 難度
- 5/5
- 預估耗時
- 一週以上
- 活躍度
- 活躍
- 描述清晰度
- 基本清楚
- 新手友好度
- 35/100