这是什么？

你有几个选择

• 我在Rust中乱搞，纯属好玩（只是个爱好，不会像pip那样大而严肃）

• Python打包标准的不完整但功能性的Rust实现，包括基于PubGrub算法（由pubgrub提供）的完整解析器。

• “PyBi”文件的草案规范，类似于wheel，但用于Python解释器。

将来

• 一个面向项目的Python工作流程管理器，旨在帮助初学者编写他们的第一个Python脚本或笔记本，然后随着你的成长，开发具有许多贡献者的复杂独立应用程序和库。

• pyenv、deadsnakes、tox、venv、pip、pip-compile/pipenv和PEP 582的合并替代品，全部在一个单文件可执行文件中，无需任何系统要求（甚至不需要Python）。

• 一头🐘 大象 🐘

愿景

目标是让posy成为Python的一种高级前端：你安装posy，然后运行posy [args] some_python.py，它会处理所有事情直到进入Python解释器。这包括

• 安装Python（posy是一个纯Rust的单文件二进制文件；它不假设你已经安装了其他任何东西）
• 从wheel/sdist安装依赖项（它是一个PEP 517构建“前端”）
• 环境管理
• （跨平台）锁定（对于解释器和包）
• 在环境中运行命令或导出一个自包含的可分发环境（例如，用于Docker镜像）
• 设置和管理这些功能的良好UX，希望如此

（注意：这些功能尚未全部实现！）

但以下内容不在范围内

• 一个 PEP 517 构建后端 backend：使用 setuptools、flit、meson-python、py-build-cmake 等，或者使用你想要的任何构建框架。如果你不是创建可重新分配的包，也可以完全不用。

  [XX TODO：一旦我们 有了分类器，我们将不再需要在这里偏袒任何项目，届时请插入 PyPI 搜索链接。]

• 一个测试框架、代码格式化工具、代码检查工具……Python 已经有很好的工具来完成这些工作，我们没有计划重复它们。但 Posy 可以设置它们所需的环境并为你运行它们！

我不打算（目前）实现的打包功能

===

PEP 440 定义了一个 === 操作符，用于比较非 PEP 440 兼容的版本。Posy 只支持 PEP 440 兼容的版本。

platform_release 和 platform_version 环境标记变量

这些值如下：

 'platform_release': '5.19.0-23-generic',
 'platform_version': '#24-Ubuntu SMP PREEMPT_DYNAMIC Fri Oct 14 15:39:57 UTC 2022',

技术上，你应该能够根据这些字符串使依赖项有所不同。但这些值非常奇怪且与机器相关，我看不出如何在 posy 的模型中实现这一点，或者为什么有人会想要它们。

在规范中指定预发布版本

根据 PEP 440，像 >= 2.0a1 这样的规范，根据版本是否包含预发布标记而改变意义。例如，>= 2.0 不 匹配 2.1a1，因为那是预发布版本，常规规范从不匹配预发布版本。但 >= 2.0a1 确实 匹配 2.1a1，因为规范中存在预发布标记，使得预发布版本匹配变得合法。

我认为我无法使用 pubgrub 系统实现这一点，因为它将同一软件包的多个规范合并为单个有效范围集合，并且无法保留有关哪些范围是从包含预发布后缀的规范中派生出来的，哪些范围不是的信息。

如果你仔细想想……这实际上是因为虽然这个规则对单独的规范来说定义得很好，但在讨论具有自身依赖关系的多个软件包时，它并没有什么意义。例如，如果软件包 A 依赖于 foo == 2.0a1，而软件包 B 依赖于 foo >= 1.0，那么安装 foo v2.0a1 是否有效？它似乎应该匹配所有要求，但技术上并不匹配……根据 PEP 440 的严格解读，一旦任何软件包说 foo >= 1.0，那么在依赖树中就永远无法在任何地方使用 foo 的预发布版本，无论其他软件包说了什么。预发布有效性本质上是全局属性，而不是单个规范属性。

因此，我认为我们应该使用以下规则：

• 如果所有可用的版本都是预发布版本，则预发布版本是有效的
• 如果我们正在更新已包含预发布版本的固定集，则预发布版本是有效的（或者至少那个特定的预发布版本是有效的）
• 否则，要获取预发布版本，您需要设置一些环境级别的配置，例如：allow-prerelease = ["foo"]。