• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

pantsbuild / pants / 28053454659 / 7
93%
main: 93%

Build:
Build:
LAST BUILD BRANCH: fix_uv_sources_config
DEFAULT BRANCH: main
Ran 23 Jun 2026 08:30PM UTC
Files 1188
Run time 51s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

23 Jun 2026 08:03PM UTC coverage: 49.524% (-0.001%) from 49.525%
28053454659.7

push

github

web-flow
Fix derived interpreter constraints for spec target when using `[python].default_resolve_to_interpreter_constraints` (Cherry-pick of #23419) (#23430)

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.

## Additional

Any chance I can have this cherry-picked into a patch version?

Co-authored-by: Nick Dell'Osa <nicholas.dellosa@joinhandshake.com>

30138 of 60855 relevant lines covered (49.52%)

0.5 hits per line

Source Files on job test_python_linux_x86_64_6/10 - 28053454659.7
  • Tree
  • List 1188
  • Changed 1
  • Source Changed 1
  • Coverage Changed 1
Coverage ∆ File Lines Relevant Covered Missed Hits/Line
  • Back to Build 28053454659
  • 0535db06 on github
  • Prev Job for on 2.32.x (#27455945338.8)
  • Next Job for on 2.32.x (#28214746973.1)
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc