fix(pydantic-ai-daytona): allow daytona SDK <1

Merged
MI
5d ago
+3-1

Why

pydantic-ai-daytona pinned the Daytona SDK to a single minor version (daytona>=0.203.0,<0.204.0). For a library that has to run next to other Daytona-dependent packages, that pin is too narrow:

  • It can't be installed in the same environment as Pydantic's native integration, pydantic-ai-harness[daytona], which requires daytona>=0.223.1,<1.
  • It locks users out of every SDK release after 0.203, including fixes this package benefits from.

What changes

daytona>=0.203.0,<0.204.0 → daytona>=0.203.0,<1

  • The floor stays at 0.203.0, the oldest SDK version the test suite has passed on.
  • <1 keeps a future 1.0 (where breaking changes are expected) from installing untested. It has the same shape as pydantic-ai-harness's own pin, so the two ranges overlap.

Verification

With the new range, against the latest SDK (daytona 0.226.1) installed alongside pydantic-ai-harness[daytona] 0.62.0 and pydantic-ai-slim 2.62.0:

  • pip check: no broken requirements
  • ruff and mypy: clean
  • Unit tests: 165 passed
  • Live tests against real Daytona sandboxes: 21 passed, cleanup verified by sandbox id

Trade-off

Before 1.0, a minor SDK release can still change an API. With a wider range, such a break would reach users before this package's CI notices, because CI only runs when the package changes. A scheduled live run would close that gap; it isn't part of this PR.

Summary by cubic

Widens the daytona SDK range in pydantic-ai-daytona from >=0.203.0,<0.204.0 to >=0.203.0,<1 so the package can be installed alongside pydantic-ai-harness[daytona] and pick up later SDK fixes.

  • Keeps the 0.203.0 floor, the oldest SDK version the test suite has passed on.
  • <1 excludes a future 1.0, where breaking changes are expected, and matches pydantic-ai-harness's own range shape.
  • Verified on the latest SDK (0.226.1) with pip check, ruff, mypy, 165 unit tests, and 21 live sandbox tests.

Trade-off

Before 1.0, a minor SDK release can still change an API, and CI only runs when this package changes, so such a break could reach users before this package's CI notices.