kaxil commented on code in PR #70497:
URL: https://github.com/apache/airflow/pull/70497#discussion_r3690141054
##########
providers/common/ai/provider.yaml:
##########
@@ -147,6 +147,16 @@ connection-types:
- hook-class-name:
airflow.providers.common.ai.hooks.pydantic_ai.PydanticAIHook
hook-name: "Pydantic AI"
connection-type: pydanticai
+ external-integrations:
+ - OpenAI
+ - Anthropic
+ - Google
+ - AWS Bedrock
+ - Groq
+ - Mistral
Review Comment:
Same vendor is "Mistral" here and "Mistral AI" in the langchain list below;
both render in the same table, so it reads as two different upstreams. Worth
picking one spelling. On the same note, the hook docstring names DeepSeek in
this hook's covered set and the langchain list includes it, so it probably
belongs here too.
##########
dev/registry/extract_metadata.py:
##########
@@ -782,12 +784,14 @@ def main():
for conn in provider_yaml.get("connection-types", []):
conn_type = conn.get("connection-type", "")
hook_class = conn.get("hook-class-name", "")
+ external_integrations = conn.get("external-integrations", [])
if conn_type:
connection_types.append(
{
"conn_type": conn_type,
"hook_class": hook_class,
"docs_url": resolve_connection_docs_url(conn_type,
conn_url_map, base_docs_url),
+ "external_integrations": external_integrations,
Review Comment:
`extract_versions.py` builds the same `connection_types` dicts (around line
394) and wasn't given this field, so per-version metadata will never carry it.
The template splits on `pv.isLatest`, which means the table shows on a release
while it's latest and then silently disappears once it's superseded.
`ConnectionTypeContract` is already reused by
`ProviderVersionMetadataContract`, so mirroring this one line there is all it
takes.
##########
providers/common/ai/provider.yaml:
##########
@@ -407,6 +430,13 @@ connection-types:
- hook-class-name:
airflow.providers.common.ai.hooks.llamaindex.LlamaIndexHook
hook-name: "LlamaIndex"
connection-type: llamaindex
+ external-integrations:
Review Comment:
This list doesn't match what the connection can reach.
`LlamaIndexHook.get_llm()` / `get_embedding_model()` only ever construct
llama-index's `OpenAI` / `OpenAIEmbedding` classes, and the hook docstring
explicitly routes Cohere, Bedrock, Vertex and HuggingFace to "instantiate the
LlamaIndex class directly in your `@task`", which bypasses the hook and this
connection entirely. Unlike `pydanticai` there is no env-var fallback path here
that could make them work, so I think the accurate list is OpenAI plus
OpenAI-compatible endpoints (Ollama, vLLM, per the hook's own placeholder), and
Anthropic is questionable for the same reason. The mirrored list in
`get_provider_info.py` needs the same edit.
##########
dev/registry/registry_contract_models.py:
##########
@@ -52,6 +52,7 @@ class ConnectionTypeContract(BaseModel):
conn_type: str
hook_class: str = ""
docs_url: str | None = None
+ external_integrations: list[str] = Field(default_factory=list)
Review Comment:
Nothing in dev/registry/tests exercises the new field; deleting the
`conn.get("external-integrations", [])` line in extract_metadata.py wouldn't
fail any test. test_registry_contract_models.py already has the legacy
connection_types payload test (around line 111) this extends naturally: assert
the field defaults to `[]` on old payloads and round-trips when present.
##########
airflow-core/src/airflow/provider.yaml.schema.json:
##########
@@ -447,6 +447,14 @@
},
"additionalProperties": false
},
+ "external-integrations": {
Review Comment:
Two thoughts on the field definition. The name sits one key away from the
existing top-level `integrations`, which describes a different axis (framework
integrations driving docs/logos/tags), so authors skimming the schema may
conflate them; something like `upstream-services` would be harder to misread.
And whatever name it lands on, it deserves a subsection in
contributing-docs/23_provider_hook_migration_to_yaml.rst next to
`ui-field-behaviour` and `conn-fields`, since that's the one place provider
authors learn the connection-types fields.
--
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]
