摘要：2024年12月17日，我们将接管 python-build-standalone 项目的管理权，这是 Gregory Szorc 用于构建和安装可移植 Python 分发版的基础项目。您可以在此处阅读 Gregory 自己的公告。

python-build-standalone 为 uv、Rye、mise、Bazel 的 rules_python、pipx、Hatch 等项目提供 Python 安装支持，自发布以来已累计 **超过70,000,000次下载**。

对生态系统的大部分而言，它现在是 Python 安装的主要来源。

但鉴于 Gregory 的开源重心发生转变，他一直在寻求帮助。自三月以来，我们一直与他合作维护 python-build-standalone 项目。我们主导了四月以来的每一个版本发布，自动化了发布流程本身，为 Python 3.13 构建了支持（包括对自由线程 Python 的支持），等等。

引用 Gregory 自己的公告，python-build-standalone“实际上是一个由 Astral 维护的项目，并且已经持续数月。” 因此，为了反映这一演变，**2024年12月17日，Gregory 将把该项目移交给 Astral 组织**，届时我们将继续维护并推动项目发展。

我们在 uv 中使用了 python-build-standalone，但它也是更广泛生态系统的一部分，未来将继续以更广泛生态系统的发展为念。我们很高兴能投入全职资源进行其维护和开发，并促进您可能从 Ruff 或 uv 所熟悉的参与度和活跃度。

什么是“独立”Python 分发版？

通常，当您在 Linux 或 macOS 上构建 CPython 时，一些系统路径会被硬编码到二进制文件中。如果您在单台机器上构建和安装 Python，这没有问题，但如果您想预构建 Python 然后将其分发到其他机器，这就会成为一个问题。CPython 还动态链接到许多系统库，如果目标机器没有安装这些库，则可能导致问题。因此，CPython 并非“独立”：它与构建它的系统紧密耦合。

因此，例如，当您在 Linux 上下载 Python（例如，从 python.org）时，您实际下载的是 CPython 源代码，然后它会在您的机器上进行构建。类似地，当您使用 pyenv 安装 Python 时，它也是从源代码构建的。

尽管源代码安装有其优点，但也有一些缺点

  1. 从源代码构建比下载预构建的二进制文件慢得多。如果您构建的是启用了优化（即 PGO 和 LTO）的 CPython，则更是如此。值得注意的是，pyenv 默认不会启用优化进行构建，因此如果您使用 pyenv 安装 Python，您将错失显著的性能提升。
  2. 从源代码构建会引入对构建工具链（例如 gcc）的依赖。而且它可能会失败！原因多种多样：缺失的依赖、不兼容的系统库等。

然而，最终结果是，您无法从……任何地方“下载 Python 二进制文件”。除了 python-build-standalone 项目。

具体来说，python-build-standalone 通过 (1) 将 Python 静态链接到其依赖项；以及 (2) 修补 CPython 构建系统，使其操作相对路径而非绝对路径来解决这些问题。

通过这些修改，它会根据广泛的 Python 版本、平台和构建变体（例如，优化版与调试版）矩阵，从源代码构建 Python，并将构建好的分发版发布到 GitHub Releases。

由 python-build-standalone 产生的 Python 构建是真正的独立版本：您可以在任何机器上下载、解压并运行它们，而无需任何额外的依赖项。它们让 uv python install 感觉像魔法一样。它不仅速度极快，而且（借用 Armin 的话）省心无忧。

独立 Python 分发版的未来

大约两年前，我刚开始从事 Ruff 的工作时，第一次遇见了 Gregory。鉴于我们都对 Rust 和 Python 感兴趣，我们偶尔会交流。

今年早些时候，Gregory 向我提及他正在寻找帮助维护 python-build-standalone 项目。鉴于我们在 uv 中使用了该项目，以及它在 Python 生态系统中扮演的关键作用，我们非常乐意提供帮助。

自三月以来，我们一直与 Gregory 合作维护该项目，推出改进，并管理版本发布，使其与最新的 Python 补丁版本和次要版本保持同步，并响应安全公告升级依赖项（例如 OpenSSL）等等。

现在，我们已经到了可以放心地继续管理这个项目的地步。通过将项目移入 Astral 组织，我们承诺对其进行长期维护和开发。

具体来说，我们有（至少）四个目标

  1. 使项目与 Python 版本保持同步更新。 每年都会有新的 Python 次要版本发布；而且每年 Python 构建系统都会发生变化。我们希望确保 python-build-standalone 跟上这些变化，一旦有稳定的版本发布，无论是补丁版本还是新的次要版本，都能尽快提供最新的 Python 版本。
  2. 将更改上游到 CPython 构建系统。 python-build-standalone 应用到 CPython 构建系统的许多补丁都是通用改进，将使更广泛的 Python 生态系统受益。我们希望与 Python 核心开发者合作，将这些更改上游，以缩小官方 CPython 构建系统与 python-build-standalone 之间的差异。
  3. 移除项目的一些现有局限性。例如，尽管 python-build-standalone 提供了基于 musl 的 Python 构建，但这些构建与 Python 扩展模块不兼容，这在实践中是一个重大限制。
  4. 改进项目的构建和发布流程。 python-build-standalone 在每次提交和每次发布时都会构建 947个构建产物。这需要大量的构建工作！我们希望投入精力，使构建和发布流程变得简单、高效和持续。例如，我们应该持续地从 CPython HEAD（最新开发版本）构建，而不是在每次 CPython 发布时才进行。我们还可以通过超越 GitHub 的免费运行器来扩展支持的平台集合。（例如，我们可以为 ARM Windows 提供 Python 构建。）

如果您对此感兴趣，我们正在招聘！我们尤其对拥有相关构建工程经验的人才感兴趣。

感谢 Gregory

最后，我想借此机会感谢 Gregory 为 python-build-standalone 所做的一切工作——感谢他引导我们参与项目，并将项目未来的开发工作托付给 Astral。

python-build-standalone 最初是为 PyOxidizer 提供支持而构建的，但此后已发展成为 Python 生态系统的重要组成部分。该项目本身是一项巨大的技术和社会成就，Gregory 的投入和专业知识在代码库和文档中都清晰可见。

我也很感激 Gregory 将继续参与项目，因为我们将在这些基础上继续投入并发展独立 Python 分发版。