Add [tool.uv.dependency-groups].mygroup.requires-python

[Gankra]

This requires some more tests and almost certainly some error messages, but, I think this is the implementation?

The first commit is a large driveby move of the RequiresPython type to uv-distribution-types to allow us to generate the appropriate markers at this point in the code. It also migrates RequiresPython from pubgrub::Range to version_ranges::Ranges, and makes several pub(crate) items pub, as it's no longer defined in uv_resolver.

Fixes #11606

[Gankra]

Note: the legacy special tool.uv.dev-dependencies group gets injected post-flattening. Currently this means we don't support tool.uv.dependency-groups.dev.requires-python affecting it. I think this is fine (you can just migrate to dependency-groups.dev if you want to apply requires-python to it).

[zanieb]

Can we error eagerly if you use both?

[Gankra]

Hmm... like "you're using Modern dependency-groups features, please migrate off Legacy dependency-groups?" even if there's no actual interaction with how they're using them?

[konstin]

I find the current behavior around adding markers to the group members unintuitive:

[project]
name = "debug"
version = "0.1.0"
requires-python = ">=3.9"
dependencies = ["typing-extensions"]

[dependency-groups]
docs = ["sphinx"]

[tool.uv.dependency-groups]
docs = { requires-python = ">=3.12" }

When I now run

uv run -p 3.11 --group docs sphinx-build

it fails to run sphinx, but it doesn't tell me that the docs groups requires a newer Python version. I would have expected this call to fail and report that I need at least Python 3.12. Similar to how the project requires-python works:

$ uv run -p 3.8 --group docs sphinx-build
Using CPython 3.8.18 interpreter at: /home/konsti/.local/bin/python3.8
error: The requested interpreter resolved to Python 3.8.18, which is incompatible with the project's Python requirement: `>=3.9`

[Gankra]

I agree I'd prefer a better diagnostic, zanie mentioned last week that I might need to do some work on... i think they said "resolver hints" or something? Or are you saying lowering to markers is entirely wrong, and I need to be resolving this metadata in a different part of uv?

[konstin]

My preference is that the requires-python is a mandatory bound, so uv run -p 3.8 --group docs sphinx-build would error. This would match the name requires-python and how project.requires-python works (both for the current project and transitively). If we're implementing the current mechanism of adding this as markers to each requirement, I would choose a different name for it to make the semantic differences with requires-python clearer.

Separately, do want to land baf9895 as a split out PR? r+ me it's a pure refactoring anyway.

[Gankra]

Separately, do want to land baf9895 as a split out PR? r+ me it's a pure refactoring anyway.

The ranges migration is good but if moving it out of the crate is based on me misunderstanding this problem I'd rather not land that part.

[Gankra]

I'll take a closer look at how the top-level requires-python is implemented to better understand what that impl would look like.

[zanieb]

Konsti is talking about confirming the selected Python interpreter meets the resolved requires-python range for the group. You'll need to ensure we're taking the fully resolved requires-python request into account when selecting a Python interpreter.

Separately, what I was talking about, is if there are conflicts between the requires-python in multiple groups or with the project.requires-python.

[konstin]

My preference is pretty much #11606 (comment): I think the current changes are required to get the right resolver behavior (split at the reuires-python version and resolve the dependencies only in the upper split, since e.g. sphinx has a higher requires-python itself and otherwise fails to resolve; Adding the markers should facilitate that), but I think we should also error when the Python version is too low for the group. CC @zanieb wdyt?

[zanieb]

Yes, that's correct.

[Gankra]

This is now an opportunity for us to emit a Better diagnostic suggesting group-requires-python (let's make this a followup...).