| 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。
设计
此设计为所有 Fuchsia 项目 Python 源代码使用供应商预构建的 Python 解释器替换用户的本地主机环境。此供应商提供的 Python 将是受支持的 Python 语言修订版本。
当前供应商提供的 Python 版本应保留在当前的 python.org 支持窗口中。随着 Python 版本的更新，将提供合理的过渡期，使源代码与新语言版本兼容。
对于 Fuchsia 项目 Python 源代码，此 RFC 终止了对 3.8 之前的 Python 语言版本的支持
- 此后，Python 2.7 将被废弃。
- 不要求向后兼容 3.8 版本。
以脚本形式提供 Python 源代码
例如，可以在命令行上调用 Python 源文件或将其作为参数提供给 Python 解释器的调用，从而以脚本的形式调用 Python 源文件。脚本由模块 __name__ 设置为 "__main__" 的运行时环境来表示。
必须执行可执行 Python 源代码，以遵循供应商提供的 Python 来执行相关操作。这可以通过不同的方式实现：
- 通过文档，指示用户直接调用供应商提供的解释器，并将候选脚本作为解释器参数提供。
- 使用封装脚本或其他机制，该机制包含足以调用解释器的逻辑（例如，使用
//scripts/hermetic-env之类的内容）来遵循供应商提供的 Python。 - 假设有一个脚本解释器来源指令（即 Shebang），该指令最终导致使用 vendor 解释器来执行脚本。
Python Shebang
旨在直接调用的 Python 脚本必须包含最终引用供应商提供的 Python 的 Shebang。应使用的适当 Shebang 行是：
#!/usr/bin/env fuchsia-vendored-python
由于使用 Shebang 意味着依赖于主机环境，因此，我们特意选择此 shebang，以实现以下封闭驱动型目标：
- 与用户主机环境中的现有工具、别名或宏冲突的可能性较低。
- 与用户向其
$PATH添加//.jiri_root/bin的顺序无关。
封闭 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.Spec protobuf 必须反映当前支持的语言版本。在符合当前受支持语言版本的前提下，可以使用 vpython 轮子。
实现
Fuchsia 项目代码库中的所有 Python 源代码都将在 2021 年第 3 季度末更新到 3.8 版本。这些要直接调用的源代码将根据以下语义将指向供应商提供的 Python。
为了便于将供应商提供的 Python 解释器作为 Shebang 目标，将修改以下内容：
- 系统会向
//.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，下载预构建二进制文件并将其安装到相应位置。 - 向
//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，这种变更应该不会出乎意料。