kaxil opened a new pull request, #76503: URL: https://github.com/apache/airflow/pull/76503
The root `pyproject.toml` held openai on 2.x with `override-dependencies = ["openai>=2.47.0,<3"]` (#73511). That kept two packages that cap openai below 3 installable next to `pydantic-ai-slim[openai]`, which needs `openai>=3.31` from 2.33 on. The cost was that CI, the CI image and the constraints file ran Common AI's OpenAI path (and the OpenAI provider) on an openai major that pydantic-ai does not declare support for, while a user who runs `pip install apache-airflow-providers-common-ai[openai]` gets openai 3. This removes the override. Each of the two caps is handled where it enters the lock: | Cap | Comes from | Change | | -- | -- | -- | | litellm `openai<3` (stable releases before 1.108) | Google provider's `google-cloud-aiplatform[evaluation]`, which caps litellm at `<1.86` (`<1.97` on 3.14) | Depend on plain `google-cloud-aiplatform` plus the extra's other dependencies. litellm leaves the lock entirely. | | `llama-index-llms-openai` `openai<3` (0.8.3, latest; run-llama/llama_index#22939 still open) | Common AI's `llamaindex` extra and dev group | Declare `llamaindex` and `openai` as conflicting extras in `[tool.uv]`, drop llama-index from the dev group, and run the LlamaIndex tests in the agent framework job. | With both gone, the `azure-ai-projects<2.5` constraint, which only existed because the override hid `azure-ai-projects`' `openai>=3`, goes too, along with its floor-bump exclusion. Result on `uv lock`: litellm is removed, and openai forks into 3.42.0 for everything except the `llamaindex` extra, which keeps 2.54.0. A frozen `uv sync --all-packages --group ci-image` in the CI image (Python 3.11) installs openai 3.42.0 without llama-index or litellm, and `pip check` passes. On that install, the Common AI and OpenAI unit tests, the Azure AI agents hook tests and the Vertex AI generative model hook and operator tests pass: 4865 passed, 11 skipped. ## Design rationale **Why dropping litellm is safe for the Google provider.** In the `google-cloud-aiplatform` 1.164.0 wheel, the only module that imports litellm is `vertexai/_genai/_evals_common.py`, behind `try: import litellm / except ImportError`. The provider's `GenerativeModelHook` uses `vertexai.preview.evaluation`, which never imports it, and `EvalTask` imports in the image without litellm. The extra's other dependencies (pandas, jsonschema, pyyaml, ruamel.yaml, scikit-learn, tqdm) are listed directly so installs are otherwise unchanged. This also removes Google's litellm cap from Airflow installs, which today blocks the fix for a critical litellm advisory (googleapis/python-aiplatform#7252). **Why move LlamaIndex out of the image instead of the OpenAI path.** The two extras cannot be installed together anyway: every `pydantic-ai-slim[openai]` the `openai` extra allows (`>=2.36`) needs openai 3, and `llama-index-llms-openai` caps it below 3, so with the override CI was testing an environment nobody can install. OpenAI backs Common AI's OpenAI and OpenAI-compatible models, `@task.llm_batch` and the OpenAI provider; the LlamaIndex integration is one hook and two operators. So the OpenAI side gets the image, and each side is now tested on the openai major its users install. The LlamaIndex tests still run on every PR that can break them, because the agent framework job already runs on changes to `providers/common/ai`, `common.sql` or `uv.lock`. It gains a `llama-index` matrix entry that installs Common AI's `llamaindex` extra (read from its `pyproject.toml`) while holding every other image package at its installed version. Holding openai too would override llama-index's `openai<3` and run it on openai 3, so the script now lets a framework release named packages from the hold. llama-index releases `openai`, and the job still fails if anything else changes. Canary runs install it with its own pins, as for the other frameworks. In the regular unit tests, the 18 LlamaIndex hook tests that do not build a model still run; the rest skip when llama-index is missing. The removed `openai-agents<0.21` fallback only applied to an image with openai 2.x. With openai 3 in the image the job installs openai-agents 0.24.0 held against it. Checked by running the job script against a venv synced from this branch's lock (where `uv pip` targets it): | Job step | openai | Result | | -- | -- | -- | | `openai-agents` | 3.42.0, openai-agents 0.24.0 | 187 passed | | `llama-index` | 2.54.0 (released), llama-index-llms-openai 0.8.3, 784 other packages held | 201 passed | | `llama-index --framework-pins` | 2.54.0 | 201 passed | | `strands-agents` | 3.42.0 | 186 passed | The lowest-direct dependency job runs `uv sync --all-extras` inside each provider, and uv rejects syncing two extras declared as conflicting. `LOWEST_DEPENDENCIES_EXCLUDED_EXTRAS` in `entrypoint_ci.sh` leaves `common.ai:llamaindex` out (`--no-extra llamaindex`); a dry run from `providers/common/ai` fails without it and resolves with it. The contributing docs' `uv sync --all-packages --all-extras` tip now says to add `--no-extra llamaindex`. ## Gotchas - **The Google provider no longer installs litellm.** Code that relied on it arriving through `google-cloud-aiplatform[evaluation]`, such as the `vertexai` `Client().evals` path with LiteLLM models, needs to install it directly. - **`[llamaindex]` no longer installs with a constraints file built from `main`**, since that file will pin openai 3. This is documented on the LlamaIndex hook page and in the frameworks table, with the same workaround the ADK page gives for OpenTelemetry. - The `conflicts` entry and the LlamaIndex job entry can be removed once run-llama/llama_index#22939 is released. - `use_cases/compare_10k_filings.rst` asks for `[openai,llamaindex]` together, which already could not resolve before this change; it is left for a follow-up that picks a different synthesis model for that example. -- 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]
