| RFC-0129： Fuchsia 中的 Python 支援 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 在 Fuchsia 專案中，定義 Python 來源的版本管理和指令碼需求。 |
| 問題 | |
| 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年/月) | 2021-06-15 |
| 審查日期 (年/月) | 2021-09-24 |
摘要
這個 RFC 定義了 Fuchsia 專案中 Python 來源的 Python 版本管理和指令碼需求。
提振精神
在主機上，不是樹狀結構中的所有 Python 指令碼都是在確定性手冊中執行。有些指令碼假設是廠商預先建構的解譯器，有些則留給系統 Python。此外，針對單指令碼支援的 Python 版本也沒有一致性。
缺少確定性的 Python 環境會導致指令碼在環境變更時偶爾中斷 (例如移除 /usr/bin/Python 符號連結)。這會要求使用者將本機環境還原至預期狀態，或對相關指令碼進行本機修改，以便與其環境相容。
最後，自 2020 年 1 月 1 日起，Python.org 已正式停用 Python 2.x。
設計
這項設計會將使用者的本機主機環境替換為所有 Fuchsia Project Python 來源的廠商預先建構 Python 解譯器。此供應商提供的 Python SHALL 是支援的 Python 語言修訂版本。
目前廠商提供的 Python 版本 SHALL 會保留在目前的 Python.org 支援視窗中。隨著 Python 版本更新，系統將給予合理的轉換期，讓來源能與新語言版本相容。
對於 Fuchsia Project Python 來源，此 RFC 終止對 3.8 以下版本的 Python 支援
- Python 2.7 因此已淘汰。
- 3.8 以下版本不需要回溯相容性。
將 Python 來源當做指令碼
您可以透過多種方式，在指令列中叫用 Python 來源檔案，或將其做為引數提供給 Python 解譯器叫用 (例如) 使用指令碼。如果執行階段環境的模組 __name__ 設為等於 "__main__"，系統會以指令碼表示指令碼。
執行時必須將可執行的 Python 來源延後至採用廠商的 Python 執行。這可以使用不同的方式完成：
- 透過說明文件，引導使用者直接叫用提供候選指令碼做為解譯器引數的廠商解譯器。
- 使用包裝指令碼或其他機制，根據能叫用解譯器的邏輯 (例如使用
//scripts/hermetic-env之類的項目) 延遲至廠商提供的 Python。 - 假設指令碼解譯器原始碼指令 (例如 Shebang)，最終會導致指令碼透過供應商提供的解譯器執行。
Python Shebang
打算直接叫用的 Python 指令碼「必須」包含最終參照供應商 Python 的配置。適當的使用線如下：
#!/usr/bin/env fuchsia-vendored-python
由於使用堆積意味著主機環境的依賴性，所以特別設計此工作的階段，就是為了達成下列密封導向的目標：
- 比較不可能與使用者主機環境中現有的工具、別名或巨集衝突。
- 無論順序是由使用者將
//.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 時，已在 $PATH 中設定供應商的 Python。此外，vpython.Specprotobuf 必須反映目前支援的語言版本。可在符合目前支援語言版本規定的延伸環境中使用 VML 滾輪。
實作
在 2021 年第 3 季結束前，Fchsia Project 存放區中的所有 Python 來源都將更新至 3.8 版。要直接叫用的這些來源，將根據以下語意，將其建構指向廠商的 Python。
為協助供應商提供的 Python 解譯器做為最終目標，系統將修改以下內容：
- 對於
//.jiri_root/bin，系統會新增fuchsia-vendored-python符號連結，並連結至//scripts/fuchsia-vendored-python。 - 對於
//scripts，系統會新增fuchsia-vendored-python符號連結，並連結至//scripts/fuchsia-vendored-python3.8。 - 系統會將
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 或類似位置)。
新的 Python 版本有時需要透過 //integration 導入。這項程序的程序相當簡單：
- 透過
//integration，下載預先建構的二進位檔並安裝至適當位置。 - 將新的啟動指令碼 (例如
fuchsia-vendored-python3.9) 新增至//scripts。 - 將
//scripts/fuchsia-vendored-python符號連結移至新的啟動指令碼。 - (選用) 刪除舊的啟動程序指令碼。
效能
無
人體工學
符合人體工學是具有確定性的 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，這應該不會意外發生。