kaxil opened a new pull request, #67444: URL: https://github.com/apache/airflow/pull/67444
## Summary Bumps the `common.ai` provider's `pydantic-ai-slim` floor from `>=1.34.0` to `>=1.71.0` -- the first release that ships the [`pydantic_ai.capabilities`](https://ai.pydantic.dev/capabilities/) module (`Thinking`, `WebSearch`, `ImageGeneration`, `MCP`, etc.). Users can now pass capabilities through `AgentOperator(agent_params=...)` without operator-level support landing first. A new example DAG (`example_agent_capabilities.py`) shows three patterns: `Thinking` alone, `WebSearch` alone, and composition with `SQLToolset`. The `agent.rst` guide gains a "Capabilities (pydantic-ai)" section. ## Why this floor (1.71.0, not 1.100.0) Capabilities first ship at [1.71.0](https://github.com/pydantic/pydantic-ai/releases/tag/v1.71.0). Anything earlier doesn't have `pydantic_ai.capabilities` and would fail to import the new example DAG. The "obvious" choice -- bumping to 1.100.0 (the V2-prep cutoff) -- was rejected for three reasons: 1. **Avoids a `fastmcp` major bump** for users with the `[mcp]` extra. Between 1.71 and 1.100, pydantic-ai's `mcp` extra switches from `mcp>=1.25` to `fastmcp-slim[client]>=3.3` -- a 2.x → 3.x major. Stopping at 1.71 keeps the existing `mcp` API. 2. **Avoids a flood of V2-prep deprecation warnings** for users who write their own pydantic-ai code in DAGs. Deprecations marked between 1.71 and 1.100 (e.g. `Usage`, `request_tokens` / `response_tokens`, `stream_responses`, `MCPServerHTTP`, `GeminiModel`, `OpenAIModel`) would otherwise start surfacing in their task logs. 3. **Defers the pydantic-ai 2.0 migration** to a separate PR with its own ramp. The `pydantic>=2.12` floor that pydantic-ai 1.71 requires is also imposed by anything later -- not avoidable if we want capabilities at all. ## Behavior changes For users on the `[mcp]` extra: no change (still `mcp>=1.25`, no `fastmcp`). For everyone else: `pydantic-ai-slim` resolves to 1.71+ on fresh installs. Existing pinned environments are not forcibly upgraded -- this is a floor bump, not an upper-bound change. ## Capabilities and serialization `agent_params` is a templated field. Airflow serializes template fields by calling `str()` on values it doesn't natively understand, so live capability instances do not round-trip through `SerializedDAG`. The example DAGs and the `.. warning::` block in `agent.rst` reflect this: capabilities are constructed inside the `@dag` function, not at module level, and a first-class `capabilities=` kwarg on `AgentOperator` (with serializer hooks) is filed as a follow-up on the [AIP-99 project board](https://github.com/orgs/apache/projects/586). ## Verification - 285 unit tests pass against `pydantic-ai-slim==1.71.0` (lowest direct floor) - 285 unit tests pass against `pydantic-ai-slim==1.102.0` (latest 1.x) - All 3 example DAGs discover cleanly via `DagBag` on the new floor - Zero pydantic-ai deprecation warnings against `common.ai` code at either end - Ruff, ruff-format, license-header, uv-lock prek hooks all pass ## Follow-ups Tracked as draft items on https://github.com/orgs/apache/projects/586: - Promote `capabilities=` to a first-class kwarg on `AgentOperator` / `LLMOperator` - Decide OpenAI default once pydantic-ai 2.0 flips `openai:` to Responses API - Rewrite `LoggingToolset` as a `Logging` capability - Reframe HITL Review as a `HITLReview` capability - Build `AirflowBudget` capability for cost/token controls - Migrate `CachingToolset` / `CachingModel` durability to an `AirflowDurability` capability -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
