Enable extra build dependencies to 'match runtime' versions

[charliermarsh]

Summary

This is an alternative to #14944 that functions a little differently. Rather than adding separate strategies, you can instead say:

[tool.uv.extra-build-dependencies]
child = [{ requirement = "anyio", match-runtime = true }]

Which will then enforce that anyio uses the same version as in the lockfile.

[charliermarsh]

(Need to rebase this, then fix the TODO I commented-on above.)

[charliermarsh]

I addressed the remaining TODOs, should be ready for review.

[konstin]

Is it intentional that extra build dependencies work in uv pip too, but match-runtime = true is limited to project mode, while being ignore in uv pip mode? (I can make an MRE if helpful)

[charliermarsh]

We could make it work in uv pip, probably.

[zanieb]

It seems fine to defer that to start.

[charliermarsh]

It could help inform the name though... If we intend for that to work, then it's another point against things like locked or match-lockfile etc.

[zanieb]

This name has sort of grown on me, fwiw. The entire field is in preview too, so we have some leeway here.

[konstin]

I'm always in favor of smaller PRs and adding this another PR :) I do see the current behavior (match-runtime is ignored in uv pip without warning) as a blocker to stabilization, we should interpret the extra build deps table the same between project mode and uv pip for extra build dependencies.

[konstin]

We should call this requires instead of requirement to by consistent with PEP 517 (It's still a str here and a list in PEP 517, but it's the same key)

[zanieb]

I don't think I agree — I don't think that's particularly clearer and matching build-requires isn't really a goal here, i.e., it's not called extra-build-requires.

[konstin]

Can you add a test where we change the requirement in a compatible way (say anyio>3.1 to anyio>3.2) to track whether we rebuild?

[zanieb]

What happens if the requirement has a pin or constraint that's incompatible with the runtime dist version? We should error, right?

[charliermarsh]

I was considering erroring entirely if a version specifier or constraint is provided with match-runtime = true. What do you think?

[charliermarsh]

It would be relatively easy to support preserving both though. We'd just add a new requirement here rather than overwriting, and let the resolver do the rest.

[zanieb]

It seems okay to eagerly fail if any constraint is provided. It's plausible someone will have a use-case for it? but I can't think of one right now.

[zanieb]

I think letting the resolver handle it sounds cool, but we'd probably need to add a hint to the error for it to be a good experience and that sounds like more work we don't want to tackle rn.

[charliermarsh]

Okay, made it reject for now.