| RFC-0129：Fuchsia 中的 Python 支援 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 定義 Fuchsia 專案中 Python 來源的控版和指令碼需求。 |
| 問題 | |
| Gerrit 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2021-06-15 |
| 審查日期 (年-月-日) | 2021-09-24 |
摘要
本 RFC 定義 Fuchsia 專案中 Python 來源的 Python 版本管理和指令碼需求。
提振精神
在主機上，樹狀結構中的 Python 指令碼並非全都會以決定性方式執行。部分指令碼會假設有供應商提供的預先建構解譯器，其他指令碼則會留給系統 Python。此外，就每個指令碼支援的 Python 版本而言，也沒有一致性。
如果沒有確定性的 Python 環境，當環境變更時 (例如移除 /usr/bin/python 符號連結)，指令碼偶爾會中斷。使用者必須將本機環境還原至預期狀態，或對相關指令碼進行本機修改，使其與環境相容。
最後，自 2020 年 1 月 1 日起，Python 2.x 已由 python.org 正式終止。
設計
這項設計會為所有 Fuchsia 專案 Python 來源，以供應商預先建構的 Python 解譯器，取代使用者的本機主機環境。這個供應商提供的 Python 應為支援的 Python 語言修訂版本。
目前的供應商 Python 版本應保留在目前的 python.org 支援視窗內。Python 版本更新時，我們會提供合理的轉換期，讓來源與新語言版本相容。
對於 Fuchsia 專案的 Python 來源，這項 RFC 會終止支援 3.8 之前的 Python 語言版本
- Python 2.7 將於日後淘汰。
- 3.8 之前的版本不需具備回溯相容性。
將 Python 來源視為指令碼
您可以透過指令列叫用 Python 來源檔案，或將其做為引數提供給 Python 解譯器，藉此將來源檔案叫用為指令碼。指令碼是由模組 __name__ 等於 "__main__" 的執行階段環境所表示。
可執行的 Python 來源「必須」延後執行，並改用供應商提供的 Python。這項作業可透過多種方式完成：
- 透過文件，指示使用者直接叫用供應商提供的解譯器，並將候選指令碼做為解譯器引數提供。
- 使用包裝指令碼或其他機制，將 Python 延後至供應商，其中包含足夠的邏輯來叫用解譯器 (例如使用
//scripts/hermetic-env)。 - 假設指令碼解譯器來源指令 (即工作行) 最終會導致指令碼使用供應商提供的解譯器執行。
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 的 args 叫用供應商 Python 解譯器，例項化 venv。這會在 my_venv 本機目錄中組裝 venv。然後，即可按照一般 venv 用法啟動 venv 並與其互動。允許安裝 venv-local 套件。
Chromium vpython
vpython 公用程式是另一種形式的密封式 Python 環境管理工具。這個函式會從 $PATH 取得解譯器，並假設第一個解譯器的 --version 與輸入 vpython.Spec protobuf 相容。如要使用 vpython，請確保在叫用 vpython 時，$PATH 中已設定供應商提供的 Python。此外，vpython.Spec protobuf 必須反映目前支援的語言版本。只要符合目前支援的語言版本，即可使用 vpython 輪子。
實作
Fuchsia 專案存放區中的所有 Python 來源，都會在 2021 年第 3 季結束前更新至 3.8 版。根據下列語意，預計直接叫用的來源會將 Shebang 指向供應商的 Python。
為方便將供應商提供的 Python 解譯器做為 shebang 目標，系統會修改下列項目：
- 如要
//.jiri_root/bin，系統會新增連結至//scripts/fuchsia-vendored-python的fuchsia-vendored-python符號連結。 - 系統會新增連結至
//scripts/fuchsia-vendored-python3.8的fuchsia-vendored-python符號連結，//scripts 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 版本。操作程序很簡單：
- 透過
//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，因此這項變更應該不會令人意外。