feat: Support tool.uv.extra-build-dependencies in annotation loading

[konsti-openai]

Currently, annotations.toml supports declaring extra build dependencies in a format that runs parallel to tool.uv.extra-build-dependencies. This PR adds support for loading uv's tool.uv.extra-build-dependencies to rules_py's uv.project. This moves rules_py closer to uv's interface.

Unlike annotations.toml, tool.uv.extra-build-dependencies supports the full requirements syntax.

---

Changes are visible to end-users: yes/no

• Searched for relevant documentation and updated as needed: yes
• Breaking change (forces users to change their own code or config): no
• Suggested release notes appear below: yes

Test plan

Extended the existing e2e snapshot test on top of uv-sdist-fallback to cover both the old and the new syntax for two different packages.

[CLAassistant]

All committers have signed the CLA.

[konsti-openai]

I'm new to rules_py, so I'm interested in feedback in how to expose this best: Should we just load extra build dependencies by default? Should this be a separate command similar to unstable_annotate_packages?

[jbedard]

Should we just load extra build dependencies by default?

I assume we should by default if that is what uv does.

Is there any known reason for disabling it? Can we just enable this 100% of the time and drop this attribute?

[konsti-openai]

I'm not aware of any, dropped!

[jbedard]

Should we still be testing both though? Or is this old/deprecated enough we can just delete it (instead of commenting it out like this)?

[konsti-openai]

I kept it there to not confuse user who come across the old format. imho it's fine to keep both format around and avoid breaking users, the comment should help users to understand what they should use and why they may see something different in existing code.

[tamird]

This currently accepts only a narrow subset of uv's extra-build-dependencies syntax and silently drops several valid cases. Please either preserve uv's semantics for requirement objects, markers, split versions, and build-only dependencies or explicitly reject unsupported forms, and add an e2e case whose build really depends on the annotation.

[tamird]

Resolving the annotated package only through default_versions silently skips every valid split-version lock: that map is populated only when a name has one version, while uv applies the annotation by package name across selected versions. The same issue affects build dependencies below. Please expand the target/dependency resolution over package_versions and add a conflicting-version or platform-fork regression.

[konsti-openai]

I've added that, though it's important to note that build-system.requires extracts only the name (

rules_py/uv/private/sdist_configure/detect_native.py

Lines 124 to 128 in 5204fc2

	requires = [
	_extract_name(r)
	for r in build_system.get("requires", [])
	if _extract_name(r)
	]

), so we have a divergence between how tool.uv.extra-build-dependencies and build-system.requires are parsed.

[konsti-openai]

Codex also flagged two other problems. They are already present with annotations.toml, so I'm cutting scope here:

• Dependency-group independence: build dependencies resolve through the active runtime group. If a required build package exists only in another group, Bazel analysis can fail.
• Version preservation: although an annotation can resolve a specific build-dependency version, the generated package alias may select the version associated with the active runtime group instead.

[konsti-openai]

It's arguable whether this should or shouldn't fail. Codex complains that this fails for wheel-only packages while annotations.toml skips, but OTOH annotating a wheel-only package with requirements missing in the lock sounds bogus.

[konsti-openai]

I'm having a hard time scoping this against preexisting gaps and making this too large for review, but I think the current state is ready for a review.