uv 与 ty 整合：Python 开发新体验
Bringing uv and ty together
Astral 宣布 uv 与 ty 的实验性整合正式上线，为 Python 开发者带来更流畅的工具链体验。通过 PEP 723 内联元数据，ty 现在能自动识别脚本依赖并调用 uv 构建环境，实现编辑器内的类型检查与代码导航。同时，新增的 uv check 命令将依赖同步与代码检查合二为一，支持单脚本或整个工作区的一键检查。这一整合不仅简化了开发流程，还为未来结合依赖分析与代码检测的新功能打下基础。
通过结合 uv 对项目环境的理解与 ty 对代码的解析，我们解锁了单一工具无法实现的全新功能。
HN 评论区
109- miki123211
我是 Python 程序员。我喜欢 Astral；我觉得 Ruff 很棒，uv 更是颠覆性的，但我其实不太喜欢 ty。
我希望我的类型检查器能检查类型，并在无法确定时对我大喊大叫。我不希望它搞什么“渐进式类型”，如果它不确定某个东西的类型，我希望这直接算作失败，而不是去建模这种不确定性却对潜在错误视而不见。我们身处智能体（agents）的时代，时不时加个额外的类型注解已经不是什么大问题了。
Meta 的 Pyrefly 大体上做到了我想要的。我也不是特别爱 Pyrefly；我不喜欢它处理边缘情况的方式，也不喜欢它赋予某些流行包（Pydantic、Django、attrs）垄断地位，而不是提供通用机制让不那么流行的包也能利用。但仅就类型检查而言，它非常出色。
- assumed_throwaw
我很喜欢 Astral 的工具，但我疑惑为什么 CLI 感觉如此支离破碎。
- 现在 ty 已集成到 uv 中，而 ty 在技术上属于 ruff 的一部分 [1]，但 ruff 却没有集成到 uv 中。
- 格式化器是 ruff 的一部分，但 uv 也有一个未文档化的 "format" 命令，且结果并不一致。
- 实际上，ruff 确实集成到了 uv 中，但你必须通过 "uv tool run ruff" 来调用它。
我想 "uv format" 和 "uv lint" 应该成为标准命令。
[1] https://github.com/zed-extensions/pyrefly/issues/26#issuecom...
- WhyNotHugo
我不喜欢这种将独立工具混合在一起的做法。ty 目前在非 uv 项目上完全可用。uv 有很多主观的怪癖，比如自定义的 lockfile 以及其他许多我们都不喜欢的细节——ty 作为一个独立工具，完全可以配合 plain pip 加上任何其他依赖管理器（例如：pip-tools）工作。
不过值得注意的是，ty 并不需要集成到 uv 中，反之亦然；保持它们作为独立工具似乎更自然。
- olive-n
感觉 Pyrefly 在过去一年里势头不错。我这周刚开始用它。
这看起来像是 Astral 意识到自己在类型检查器的竞争中落败，现在把它并入他们流行的项目中，好让人们有理由去使用它。
如果它已经随 uv 安装了，人们寻找其他类型检查器的动力就会减少，只会继续使用默认选项。
- shahbazac
我不喜欢 'uv run …' 以及其他工具干扰脚本或程序运行的做法。我希望核心 Python 开发者能着手“保护”使用 Python 的主要接口。我这么说并非出于敌意，而是越来越多的软件快速入门和安装页面都要求使用 uv、conda、20 种变体的 venv 等等。
工具链显然存在缺口。我们已经经历了工具的大爆发，尝试过许多选项。现在是时候让核心 Python 团队介入，整合生态系统了。
- bitpush
我真的很喜欢 uv，但这篇关于 uv-ty 的帖子看起来像是“按组织架构发货”（shipping the org chart）？
他们本可以直接说 uv 现在具备了类型检查能力（或者不管叫什么……）。据我所知 ty 并不是一个超级流行的品牌，所以这篇帖子反而让人得先搞懂 ty 是什么……
- thayne
ty 集成到 ruff 里似乎比集成到 uv 里更有道理。
- xavdid
啊，这太棒了！这是解决我对 PEP 723 脚本最大不满的一大步：糟糕的编辑器支持。
我在纸面上很喜欢这个想法，但在手动创建匹配的 venv 并安装依赖之前，开发过程中无法获得编辑器内的自动补全。对于小项目这还行，但随着脚本变大就变得无法忍受了。所以我其实很少使用这个功能，因为直接搭建一个真正的开发环境更有意义。
很高兴看到这里会有改进！