在 PyCon US 2025 上，Barry Warsaw 和 Jonathan Dekhtiar 介紹了 WheelNext，這是一個由社群推動的計劃，旨在革新 Python 的套件封裝生態系統，特別是 wheel 格式，因其在現代需求下逐漸顯露不足。
Python 的套件封裝生態系統是其廣泛採用的基石，自 distutils 和 setuptools 時代以來已有顯著進展。輪式二進位格式（wheel）和 Python 套件索引（PyPI）的引入標誌著重要里程碑，截至 2025 年，PyPI 支援超過 60 萬個項目、700 萬個版本，以及每日 16 億次下載。然而，隨著 Python 應用於科學計算、人工智能和邊緣運算等多元化領域，現有生態系統的局限性日益顯現。
WheelNext 的原因在於當前系統的挑戰：PyPI 的檔案大小限制（預設 100MB，最高 1GB 需人工審批，項目總計 10GB）阻礙了 PyTorch 或 TensorFlow 等大型 AI 和科學項目；wheel 格式無法有效支援原生依賴（如 C++、Rust 程式庫）、符號連結或 Zstandard 等現代壓縮技術；同時，缺乏針對特定硬體（如 GPU 或 AVX512 支援的 CPU）選擇優化輪式套件的機制。此外，多個套件索引的管理帶來安全風險，因惡意套件可能透過較高的版本號被優先選擇，且 pip 的多索引介面使用不便，影響可用性。
WheelNext 的目的是打造一個強大、向後兼容且以用戶為中心的封裝生態系統，滿足用戶、工具開發者、安裝程式和套件創建者等不同利益相關者的需求，同時避免形成孤立解決方案。
WheelNext 旨在簡化套件安裝流程，支援新興使用場景，並在整個生態系統中標準化實踐。例如，科學計算項目如 NumPy 常需重複打包 OpenBLAS 等程式庫，導致套件過大和運行時記憶體浪費。WheelNext 提議高效共享此類程式庫，可能透過類似 importlib 的標準化原生程式庫載入器。該計劃還引入「wheel 變體」概念，允許安裝程式根據系統功能（如 PyTorch 的 CUDA 版本或 JAX 的 TPU 支援）動態選擇最適套件，取代當前「最低共同標準」的做法，後者無法為任何人提供最佳化。
WheelNext 提出多項 Python 增強提案（PEP）以實現這些目標。PEP 766 旨在標準化多索引優先級管理，降低安全風險並改善可用性，讓用戶可指定可信來源（如「PyTorch 從此索引，NumPy 從 PyPI」）。PEP 771 提出預設後端選項，使套件在用戶未指定偏好時安裝備房間視覺化工具或 GUI 工具包，類似 Python 的預設函數參數。PEP 778 探索符號連結支援，以跨輪式套件共享程式庫，儘管檔案系統兼容性帶來挑戰。PEP 777 尋求在不破壞向後兼容的情況下演進 wheel 格式，解決如缺乏 METADATA.json 支援依賴鎖定檔案的問題。此外，一個原型 pip 插件展示 wheel 變體，透過偵測系統特性（如 CPU 微架構、CUDA 版本）選擇最佳套件，並計劃推廣至其他安裝程式。
治理方面，PEP 772 提議仿效 Python 指導委員會模式，建立一個由封裝社群選舉的封裝委員會。目前，封裝決策依賴少數委派個人，存在「巴士因素」風險並使其負擔過重。該委員會將納入工具開發者（如 pip、conda）、科學計算社群和企業用戶等多方觀點，確保決策多元化。Warsaw 特別提到，科學計算社群因現有生態系統無法處理大型模型或特殊硬體而感到服務不足。
展望未來，WheelNext 期望 Python 在新興技術（如量子運算或邊緣設備）的封裝創新中保持領先地位。透過解決當前痛點並促進協作，該計劃旨在打造一個可擴展、面向未來的生態系統。社群參與是實現這一願景的核心。WheelNext 的 GitHub 儲存庫歡迎程式碼和使用案例反饋等貢獻，討論論壇則鼓勵所有利益相關者的意見。未來里程碑包括最終確定 PEP 772 以成立委員會，以及擴展 wheel 變體原型。
WheelNext 網站：https://wheelnext.dev/
Warsaw 和 Dekhtiar 強調，WheelNext 不僅是修復 wheel 格式，而是為 Python 的下一個十年「重新打造之輪」，誠邀所有人參與這一變革之旅。有興趣者可觀看講座的 YouTube 影片以獲取更多資訊。
