pantsbuild / pants / 27584169499

93%

push

github

Fix derived interpreter constraints for root target (#23419)

Fixes #23418.

  ## Problem

When `[python].default_to_resolve_interpreter_constraints` is enabled,
`validate_python_dependencies` should derive a target's default
interpreter constraints from its configured Python resolve when the
  target does not set `interpreter_constraints` directly.

The dependency side already did this correctly by reading
`PythonResolveField` directly from each dependency target. The root
target being validated did not: `DependencyValidationFieldSet` declared
`resolve` as `PythonResolveField | None`, and `FieldSet.create()` only
populates attributes whose annotation is a direct `Field` subclass.
Because the union annotation was ignored, the field set kept the
dataclass default of `None`, causing the root target to fall back to
global Python interpreter constraints instead of the resolve-derived
constraints.

That made validation asymmetric: the root target used global interpreter
constraints, while dependencies used resolve-derived interpreter
constraints.

  ## Solution

Change `DependencyValidationFieldSet.resolve` to be a direct
`PythonResolveField` annotation so `FieldSet.create()` includes it.
`PythonResolveField` remains optional for dependency validation because
it
is not part of `required_fields`; this preserves the existing FieldSet
optional-field pattern while allowing resolve-capable Python targets to
carry their actual resolve into validation.

The tests now cover manual interpreter constraint validation, explicit
target interpreter constraints overriding resolve defaults, and the
resolve-derived default case that reproduces the issue.

36 of 36 new or added lines in 2 files covered. (100.0%)

93175 of 100410 relevant lines covered (92.79%)

3.69 hits per line