Repository navigation
Conversation
a5292df to
5479098
Compare
|
@Lee-W Screenshots would be very helpful |
5479098 to
0595000
Compare
|
0595000 to
9c161ee
Compare
kaxil
left a comment
kaxil
left a comment
There was a problem hiding this comment.
One thing I am concerned about is -- "toolsets" is the concept of Common AI provider and doesn't apply more generally to other providers. So calling it toolsets is weird.
I wonder if you can do something specific to only Common AI provider for now.. even if needs to be manually maintained (ideally not)
9c161ee to
a04ddd2
Compare
a04ddd2 to
e3e4543
Compare
|
Moved the toolset into common.ai. Remove
The Toolsets table on the Supported services page is now hand-written in the common.ai docs. |
Readers had no single place to see what this provider reaches. The answer was spread across the toolsets guide, the index page, seven connection pages and provider.yaml, so the differentiating half — the Airflow hooks, MCP servers, SQL warehouses, DataFusion tables, sandboxes and vendor-managed agents a toolset gives you over a raw SDK call — was effectively unwritten. The model list had also drifted. It was a hand-copied snapshot of nine vendors while the connection actually resolves anything pydantic_ai.providers can construct, so services we already support, Snowflake Cortex and OpenRouter among them, were absent from the page a customer searches. Making provider.yaml the one source both the page and the registry read keeps them from disagreeing, and a test that derives the reachable set from pydantic-ai turns a drift into a red build naming the vendor rather than a quiet omission. That list is derived from a current pydantic-ai, while the provider supports pydantic-ai-slim from 2.23.0 upward and CI exercises exactly that floor. Snowflake Cortex and Crusoe reach back only to 2.27.0 and 2.28.0, so a vendor being absent downstream is a version difference rather than drift. The test therefore asserts on every supported version that an installed vendor is declared, and defers the opposite direction to the release that carries all of them.
Toolsets are a common.ai concept rather than a provider-wide one, so a provider.yaml schema field and a globally registered Sphinx directive for them would invite other providers to adopt a shape that does not apply to them. The toolset table now lives with the common.ai docs and is guarded by the provider's own metadata tests; the connection-type services table keeps using the shared mechanism, since that field already exists for every provider.
The bumped pydantic-ai-slim ships GitHub Copilot, OpenAI Codex and vLLM provider modules. GitHub Copilot and vLLM take the api_key and base_url the pydanticai connection passes, so they are reachable and listed. OpenAI Codex only reads credentials produced by the Codex CLI OAuth login, which no connection field can express, so it stays off the list.
… list pydantic-ai-slim 2.48 ships a TypeSafe provider module. It takes the api_key and base_url the pydanticai connection passes, so it is reachable and listed. It first appears in 2.45, above the 2.33 floor the low-dep job installs, so the "declared but absent upstream" checks start from there.
0f6d901 to
1a73cb0
Compare
|
Toolsets external-services tracking moved off provider.yaml's schema and the shared Sphinx directive entirely. It's a hand-maintained table in supported_services.rst now, and four drift tests in test_provider_metadata.py catch a missing entry, a stale one, or a broken doc target. The dangling file citation in the module docstring is gone too, with the derivation documented at each constant instead. GitHub Copilot and vLLM are reachable through the pydanticai connection and now listed. OpenAI Codex stays off because it only reads OAuth credentials the hook has no way to pass, and TypeSafe landed with the version floor bumped to 2.45 to match.
Good to merge from me. |
|
@kaxil Thanks for taking another look. But will need your help revoke request change and approve before we can merge it. Thanks! |
This branch has not been deployed
2 participants
Why
Nothing told a user what
common.aiactually reaches — the answer was spread across the toolsets guide, the index page, seven connection pages andprovider.yaml, so the differentiating half (the Airflow hooks, MCP servers, SQL warehouses, DataFusion tables, sandboxes and vendor-managed agents a toolset gives you over a raw SDK call) was effectively unwritten.The model list had also drifted: it was a hand-copied snapshot of nine vendors while the connection resolves anything
pydantic_ai.providerscan construct, so services we already support — Snowflake Cortex and OpenRouter among them — were absent from the page a customer searches.What
provider.yamlbecomes the one source the docs page and the registry read for connection types:pydanticaiandmcpget theirexternal-serviceslists completed, including the vendors pydantic-ai added up to 2.48.provider-connection-servicesdirective renders those lists as a table on a new Supported services page, listed in the provider's Guides and cross-linked with Models and providers.test_provider_metadata.pykeeps it in step with the toolset modules and their doc pages.Was generative AI tooling used to co-author this PR?
Generated-by: [Claude] following the guidelines
{pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.