| 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.org 已正式停用 Python 2.x。
设计
此设计使用供应商提供的预构建 Python 解释器替换了用户的所有 Fuchsia 项目 Python 源代码的本地主机环境。此供应商提供的 Python 必须是受支持的 Python 语言修订版本。
当前随附的 Python 版本应保持在 python.org 的当前支持窗口内。随着 Python 版本的更新，我们会提供合理的过渡期，以便使源代码与新的语言版本兼容。
对于 Fuchsia 项目 Python 源代码，此 RFC 终止对 3.8 之前 Python 语言版本的支持
- Python 2.7 即将弃用。
- 无需实现 3.8 之前的向后兼容性。
作为脚本的 Python 源代码
Python 源文件可以通过多种方式作为脚本调用，例如在命令行中调用，或作为实参提供给 Python 解释器的调用。脚本由模块 __name__ 设置为等于 "__main__" 的运行时环境表示。
可执行的 Python 源代码必须延迟到 vendored Python 执行。这可以通过多种方式实现：
- 通过文档，指示用户直接调用供应商提供的解释器，并将候选脚本作为解释器实参提供。
- 使用包装脚本或其他包含足够逻辑来调用解释器的机制（例如使用类似
//scripts/hermetic-env的内容）来延迟到供应商提供的 Python。 - 假设脚本解释器源指令（即 shebang）最终导致脚本使用供应商提供的解释器执行。
Python Shebang
旨在直接调用的 Python 脚本必须包含最终引用供应商提供的 Python 的 Shebang。要使用的适当的 shebang 行是：
#!/usr/bin/env fuchsia-vendored-python
由于使用 shebang 意味着依赖于宿主环境，因此我们有意选择此 shebang 来实现以下以 hermetic 为导向的目标：
- 不太可能与用户宿主环境中的现有工具、别名或宏发生冲突。
- 不考虑用户向
$PATH添加//.jiri_root/bin的顺序。
封闭式 Python 环境
venv 和 vpython 等工具用于组建临时且封闭的 Python 环境。安装的软件包仅限于这些封闭环境，不会影响本地系统安装库。允许使用封闭式 Python 工具，但前提是这些工具源自供应商提供的 Python。
Python VirtualEnv (venv)
通过使用 -m venv my_venv 的实参调用供应商提供的 Python 解释器，可以实例化 venv。这将在本地目录 my_venv 中组装一个虚拟环境。然后，可以按照典型的 venv 用法激活 venv 并与之互动。允许安装 venv-local 软件包。
Chromium vpython
vpython 实用程序是另一种形式的密封 Python 环境管理器。它从 $PATH 获取其解释器，并假设第一个 --version 与输入 vpython.Spec protobuf 兼容的解释器。如需使用 vpython，请确保在调用 vpython 时，已在 $PATH 中配置了供应商提供的 Python。此外，vpython.Spec protobuf 必须反映当前支持的语言版本。允许使用 vpython 软件包，但前提是它们符合当前支持的语言版本。
实现
到 2021 年第 3 季度末，Fuchsia 项目代码库中的所有 Python 源代码都将更新为语言版本 3.8。那些旨在直接调用的来源将根据以下语义将其 shebang 指向 vendored Python。
为了方便将供应商提供的 Python 解释器作为 shebang 目标，将修改以下内容：
- 对于
//.jiri_root/bin，系统将添加一个指向//scripts/fuchsia-vendored-python的新fuchsia-vendored-python符号链接。 - 对于
//scripts，系统将添加一个指向//scripts/fuchsia-vendored-python3.8的新fuchsia-vendored-python符号链接。 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，下载预构建的二进制文件并将其安装到相应位置。 - 向
//scripts添加新的引导脚本（例如fuchsia-vendored-python3.9）。 - 将
//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，因此这项更改应该不会令人意外。