目前，uv init的默认构建后端是hatchling，但未来将改为uv。uv支持所有符合PEP 517标准的构建后端，并提供了一个原生构建后端uv_build，与uv紧密集成，提升性能和用户体验。uv构建后端适用于大多数Python项目，具有合理的默认配置，支持灵活的自定义，并能验证项目元数据和结构，防止常见错误。不过，它目前仅支持纯Python代码，构建包含扩展模块的库需使用其他后端。

文章主要介绍了 uv 构建后端的使用和配置，内容涵盖了如何选择构建后端、如何使用 uv 构建后端、模块和命名空间包的配置、文件包含与排除的规则等。以下是主要内容的详细总结：

1. 构建后端概述

• 目前，uv init 的默认构建后端是 hatchling，但未来版本将改为 uv。
• 构建后端的作用是将源代码树（即目录）转换为源码分发包或 wheel 包。
• uv 支持所有符合 PEP 517 标准的构建后端，同时提供了一个原生构建后端 uv_build，它与 uv 紧密集成，以提升性能和用户体验。

2. 选择构建后端

• uv 构建后端是大多数 Python 项目的理想选择，具有合理的默认配置，目标是为大多数用户提供零配置体验，同时提供灵活的配置选项。
• 它紧密集成于 uv，改善了消息传递和用户体验，并验证项目元数据和结构，防止常见错误。
• 目前，uv 构建后端仅支持纯 Python 代码，构建带有扩展模块的库时需要使用其他构建后端。

3. 使用 uv 构建后端

• 在现有项目中使用 uv 作为构建后端，需在 pyproject.toml 的 [build-system] 部分添加 uv_build。
• 创建新项目时，可以使用 uv init --build-backend uv 命令，构建项目时 uv 构建后端将用于生成源码分发包和 wheel 包。

4. 捆绑的构建后端

• uv_build 作为独立的包发布，优化了可移植性和二进制文件大小。
• uv 可执行文件中包含一个构建后端的副本，如果版本兼容，将在构建时使用；否则将使用兼容的 uv_build 包。

5. 模块配置

• Python 包通常包含一个或多个 Python 模块，默认情况下，模块位于 src/<package_name>/__init__.py。
• 可以通过 module-name 和 module-root 设置更改默认模块名称和根目录。

6. 命名空间包

• 命名空间包用于多个包共享一个命名空间的场景，模块名称中通过 . 标识。
• 支持复杂的命名空间包结构，但不推荐使用，建议使用多包的工作区。

7. 存根包

• 构建后端支持构建类型存根包，模块名称必须以 -stubs 结尾，且会搜索 __init__.pyi 文件。

8. 文件包含与排除

• 构建后端负责确定源树中哪些文件应包含在分发包中。
• 默认情况下，uv 排除 __pycache__、*.pyc 和 *.pyo 文件。
• 包含和排除规则使用锚定的 glob 语法，包含规则是锚定的，而排除规则不是。

9. 包含与排除语法

• 包含规则使用锚定的 glob 语法，例如 src/** 会递归包含 src 目录下的所有文件。
• 排除规则不锚定，例如 __pycache__ 会排除所有名为 __pycache__ 的目录及其子目录。

通过以上总结，用户可以了解如何使用 uv 构建后端来管理和构建 Python 项目，并掌握相关的配置和最佳实践。

主要观点总结：

1. 对Astral团队的赞扬与认可

   • 多位评论者对Astral团队的工作表示高度赞赏，认为其工具（如uv和ruff）极大地改善了Python的开发体验。
   • 关键引用：
     • "uv is an absolute game changer and I can’t imagine going back to a pre-uv world."（uv绝对是一个改变游戏规则的工具，我无法想象回到没有uv的世界。）
     • "The astral tooling is by far the best thing that has happened to Python in years."（Astral的工具无疑是近年来发生在Python身上最好的事情。）

2. 对Python工具生态的批评与改进期望

   • 部分评论者指出Python工具生态复杂且混乱，缺乏统一的官方解决方案。
   • 关键引用：
     • "I wish python can provide an 'official' solution to each problem."（我希望Python能为每个问题提供一个“官方”解决方案。）
     • "how do people work like this?"（人们是怎么在这种环境下工作的？）

3. 对Astral未来商业模式的讨论

   • 评论者对Astral如何盈利表示关注，推测其可能通过企业服务或AI工具实现商业化。
   • 关键引用：
     • "keep tooling open and free forever, build enterprise services on top."（保持工具永远开源和免费，在此基础上构建企业服务。）
     • "I'm now considering that they might release 'AI' tools."（我现在认为他们可能会发布“AI”工具。）

4. 对uv工具的具体功能与优势的讨论

   • 评论者提到uv在构建速度、单仓库管理等方面的优势，认为其简化了开发流程。
   • 关键引用：
     • "uv just kinda works like you’d hope."（uv就像你希望的那样工作。）
     • "it made everything a lot faster which was awesome."（它让一切都变得更快，这太棒了。）

5. 对Python核心团队的质疑

   • 有评论者质疑Python核心团队是否错过了工具开发的机遇，或缺乏相关能力。
   • 关键引用：
     • "did the Python core team fail to see the opportunity in python tooling?"（Python核心团队是否错过了Python工具开发的机遇？）

总结：

评论整体对Astral团队的工具（如uv和ruff）给予了高度评价，认为其显著提升了Python的开发体验。同时，部分评论者对Python工具生态的复杂性和缺乏统一解决方案表示不满。此外，Astral未来的商业模式引发了广泛讨论，推测其可能通过企业服务或AI工具实现盈利。