RFC-0129：Fuchsia 中的 Python 支援

RFC-0129：Fuchsia 中的 Python 支援
狀態已接受
區域
  • 管理事宜
說明

定義 Fuchsia 專案中 Python 來源的版本和指令碼需求。
問題
Gerrit 變更
作者
審查人員
提交日期 (年-月-日)2021-06-15
審查日期 (年-月-日)2021-09-24

編輯此 RFC

編輯 RFC 中繼資料

摘要

本 RFC 定義了 Fuchsia 專案中 Python 來源的 Python 版本和指令碼需求。

提振精神

在主機上，並非樹狀結構中的所有 Python 指令碼都會以確定性方式執行。有些指令碼會假設廠商預先建構的轉譯器，其他則交由系統 Python 處理。此外，每個指令碼支援的 Python 版本並未一致。

缺少確定性的 Python 環境，會導致在環境變更時 (例如移除 /usr/bin/python 符號連結)，指令碼偶爾中斷。這會要求使用者將本機環境還原為預期狀態，或是對相關指令碼進行本機修改，以便與環境相容。

最後，自 2020 年 1 月 1 日起，Python 2.x 已正式由 python.org 停用。

設計

這項設計會將使用者的本機主機環境，替換為供應商預先建構的 Python 解譯器，適用於所有 Fuchsia 專案 Python 來源。此供應商提供的 Python 版本必須是支援的 Python 語言修訂版本。

目前供應商提供的 Python 版本應維持在 python.org 的支援時間範圍內。更新 Python 版本時，我們會提供合理的轉換期，讓來源與新語言版本相容。

針對 Fuchsia 專案 Python 來源，此 RFC 將終止對 Python 3.8 以下版本的支援

  • 因此，Python 2.7 已淘汰。
  • 不必支援 3.8 以下版本的回溯相容性。

以指令碼形式提供 Python 來源

您可以透過在指令列上叫用 Python 來源檔案，或將其做為引數提供給 Python 解譯器的叫用作業，將 Python 來源檔案做為指令碼叫用。指令碼會由執行階段環境表示，這些環境的模組 __name__ 會設為 "__main__"。

執行 Python 來源必須延遲至供應商提供的 Python 執行。您可以透過下列方式完成這項操作：

  • 透過說明文件，指示使用者直接叫用供應商提供的轉譯器，並將候選指令碼做為轉譯器引數。
  • 使用包裝指令碼或其他機制，將呼叫轉交給供應商提供的 Python，其中包含足以叫用轉譯器的邏輯 (例如使用 //scripts/hermetic-env 之類的東西)。
  • 假設指令碼解譯器來源指示 (即 shebang) 最終會導致使用供應商提供的解譯器執行指令碼。

Python Shebang

要直接叫用的 Python 指令碼，必須包含 shebang，最終才能參照供應商提供的 Python。要使用的適當 shebang 行為：

#!/usr/bin/env fuchsia-vendored-python

由於使用 shebang 會暗示對主機環境的依附性，因此這個 shebang 是刻意選取，以符合下列以密封為目標的目標：

  • 不太可能與使用者主機環境中的現有工具、別名或巨集衝突。
  • 無須瞭解使用者將 //.jiri_root/bin 新增至 $PATH 的順序。

密封的 Python 環境

venv 和 vpython 等工具可用於組合暫時性和密封的 Python 環境。安裝的套件是這些密封環境的本機，不會影響本機系統的安裝基礎。您可以使用密封的 Python 工具，但必須是來自供應商的 Python。

Python VirtualEnv (venv)

您可以使用 -m venv my_venv 的引數叫用供應商 Python 解譯器，以便將 venv 例項化。這會在本機目錄 my_venv 中組合 venv。接著，系統可能會依照一般 venv 使用方式啟用 venv 並與其互動。允許安裝 venv-local 套件。

Chromium vpython

vpython 公用程式是另一種密封 Python 環境管理工具。它會從 $PATH 取得其轉譯器，並假設第一個轉譯器的 --version 與輸入的 vpython.Spec protobuf 相容。如要使用 vpython，請確保在叫用 vpython 時，供應商 Python 已在 $PATH 中設定。此外，vpython.Spec protobuf 必須反映目前支援的語言版本。只要符合目前支援的語言版本，即可使用 vpython 輪子。

實作

在 2021 年第 3 季結束前，Fuchsia 專案存放區中的所有 Python 來源都會更新至語言版本 3.8。這些要直接叫用的來源，其 shebang 會根據下列語意指向供應商提供的 Python。

為方便供應商 Python 解譯器做為 shebang 目標，我們會修改下列項目：

  1. 在 //.jiri_root/bin 中，系統會新增連結至 //scripts/fuchsia-vendored-python 的新 fuchsia-vendored-python 符號連結。
  2. 系統會在 //scripts 中新增 fuchsia-vendored-python 符號連結，並連結至 //scripts/fuchsia-vendored-python3.8。
  3. fuchsia-vendored-python3.8 指令碼會新增至 //scripts，並以以下方式實作：
#!/bin/bash
hermetic-env python3.8 "$@"

假設 //.jiri_root/bin 是主機環境的 PATH (假設的環境設定)，無論主機上安裝的是哪個轉譯器版本，這項作業都會將工作分配給預先建構的轉譯器。

如果 //.jiri_root/bin 不是主機環境路徑的一部分，就必須將 //.jiri_root/bin/fuchsia-vendored-python 符號連結至適當的位置 (例如 ~/bin 或類似位置)。

預期不時會需要透過 //integration 推出新的 Python 版本。操作步驟很簡單：

  1. 透過 //integration，下載並將預先建構的二進位檔安裝到適當的位置。
  2. 將新的引導程式指令碼 (例如 fuchsia-vendored-python3.9) 新增至 //scripts。
  3. 將 //scripts/fuchsia-vendored-python 符號連結移至新的引導指令碼。
  4. (選用) 刪除舊的引導腳本。

成效

無

人體工學

從人體工學的角度來看，確定性的 Python 語言版本和供應商預先建構的轉譯器，將提供更舒適的體驗。使用者不會因為依賴主機環境而發生類似問題，導致速度變慢。

回溯相容性

我們不再需要 Python 語言 2.x 版的回溯相容性，因此本 RFC 將終止對 Python 語言 2.x 版的支援。這個 RFC 的目的是消除 Python 2 回溯相容性帶來的維護負擔。

安全性考量

python.org 已將 Python 2.x 列為淘汰產品，並停止所有維護作業，包括安全性修復。Fuchsia 專案不再支援 Python 語言 2.x 版。

遷移至維護的 Python 發行版 (3.8 以上版本)，以及在較新的 Python 語言版本中，位元組和字元陣列型別之間更嚴格的型別，可提升安全性。

此外，假設使用者安裝的是預先建構的版本，而非任意主機系統版本，就能減少維護負擔，並避免因版本偏差和本機安裝變化而導致開發人員感到挫折。

隱私權注意事項

無

測試

無

說明文件

請更新下列文件，以反映這項政策：

  • //docs/development/build/build_system/policies.md
  • //docs/development/languages/python/python_style.md
  • //docs/get-started/get_fuchsia_source.md

缺點、替代方案和未知事項

以不相容的方式淘汰程式設計語言修訂版本，可能會在遷移期間造成問題。並非所有使用者都會預期這項變更，有些人可能還沒有從 Python 2.x 遷移。

不過，業界早已知道需要從 2.7 遷移至 Python 3.x，這項變更並非突如其來。

既有技術與參考資料