uv最新版本中pyproject.toml工作区与可选依赖引发的‘conflicting URLs for package’依赖解析错误解决方案咨询

我完全懂你的处境——既要保留用户已经习惯的.all安装方式，又不想陷入重复维护依赖列表的麻烦，还要适配uv新版本的解析逻辑，确实头疼。

咱们先来理清楚问题根源：uv在更新版本里收紧了工作区模式下的依赖解析规则，当你在all可选依赖里写my-project[parta,partb]时，它会认为你要拉取外部的my-project包，但本地工作区已经存在同一个包的实例，这就触发了“URL冲突”的错误。旧版本uv没做这么严格的校验，所以之前能正常运行。

给你推荐一个最稳妥、长期有效的解决方案，完全符合PEP规范，还能兼顾你的需求：

修改可选依赖的all定义，直接展开子依赖列表 #

不用再通过引用自身包来聚合依赖，而是利用pyproject.toml的数组展开语法，直接复用parta和partb的依赖项。修改后的[project.optional-dependencies]部分如下：

[project.optional-dependencies]
partb = [
  "langchain-openai==0.2.8",
  "opentelemetry-exporter-otlp==1.29.0",
]
parta = [
  "overrides==7.7.0",
  "opentelemetry-api==1.29.0",
]
all = [
  *parta,
  *partb,
]

这个方案的优势：

• 零维护成本：不需要手动复制parta和partb的依赖，后续修改子依赖时all会自动同步
• 不打破用户习惯：用户依然可以用uv pip install -e .[all]命令，完全感知不到配置变化
• 从根源解决冲突：all的依赖直接是第三方包，不会再触发uv对自身包的重复解析

修改后直接运行你的安装命令，应该就能正常解析依赖了。

如果出于某些原因你不想修改all的定义，还有一个临时 workaround：安装时加上--no-resolve-workspace参数，命令变成：

uv pip install -e .[all] --no-resolve-workspace

不过这个方法不推荐长期使用，因为它会绕过uv的工作区依赖解析逻辑，可能导致其他工作区内的包无法正确关联。

内容来源于stack exchange