feat(langchain): split provider integrations into optional extras#1989
feat(langchain): split provider integrations into optional extras#1989marcusds wants to merge 1 commit into
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Enterprise Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (2)
✅ Files skipped from review due to trivial changes (1)
WalkthroughThis PR separates provider integrations from core packages by moving provider ChangesDependency Structure Refactoring
🎯 3 (Moderate) | ⏱️ ~20 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
2fbfe55 to
015729b
Compare
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
pyproject.toml (1)
1-1:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winUpdate copyright year range for consistency.
The copyright header shows only "2026", but the root
pyproject.tomlalmost certainly existed in 2025 (the package file atpackages/nvidia_nat_langchain/pyproject.tomlshows "2025-2026"). Per the guideline to "confirm that copyright years are up-to date whenever a file is changed", the range should be updated to reflect the file's history.📅 Proposed fix
-# SPDX-FileCopyrightText: Copyright (c) 2026, NVIDIA CORPORATION & AFFILIATES. +# SPDX-FileCopyrightText: Copyright (c) 2025-2026, NVIDIA CORPORATION & AFFILIATES.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@pyproject.toml` at line 1, Update the SPDX copyright header line that currently reads "Copyright (c) 2026, NVIDIA CORPORATION & AFFILIATES." to the full range "2025-2026" so it matches the repository's root/package metadata; locate the SPDX header line in this file (the first line) and replace the single-year value with the range "2025-2026" to keep copyright years consistent.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In `@pyproject.toml`:
- Line 1: Update the SPDX copyright header line that currently reads "Copyright
(c) 2026, NVIDIA CORPORATION & AFFILIATES." to the full range "2025-2026" so it
matches the repository's root/package metadata; locate the SPDX header line in
this file (the first line) and replace the single-year value with the range
"2025-2026" to keep copyright years consistent.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: a97f0628-5e74-4d8b-a798-0d7e61241918
⛔ Files ignored due to path filters (1)
uv.lockis excluded by!**/*.lock
📒 Files selected for processing (2)
packages/nvidia_nat_langchain/pyproject.tomlpyproject.toml
The nvidia-nat-langchain distribution required every supported langchain
provider integration (langchain-aws, langchain-community, langchain-oci,
langchain-openai, ...) at install time. Consumers that only configure one
provider still pulled in all of them, which bloated wheels and made pip
resolution fragile -- transitive aws/boto3 pins in particular trigger
ResolutionTooDeep failures downstream.
Every provider module is already lazy-imported inside the corresponding
register_llm_client / register_function body, so the deps were only
nominally required. Promote that reality into the package metadata:
* Core deps now cover only the langchain pieces imported at module
load time: langchain, langchain-classic, langchain-core, langgraph
(plus the existing nvidia-nat-* siblings and the pyopenssl
transitive pin).
* Each provider integration moves behind an extra: [aws], [community]
(langchain-community + wikipedia), [exa], [huggingface], [judge]
(openevals), [litellm], [milvus], [nvidia], [oci], [openai],
[tavily].
* A new [all] extra installs every provider, matching the pre-split
behavior. The top-level `nvidia-nat[langchain]` and `nvidia-nat[most]`
extras now resolve to `nvidia-nat-langchain[all]` so existing
consumers see no functional change.
Lock regenerated to reflect the new graph.
Signed-off-by: mschwab <mschwab@nvidia.com>
015729b to
47b43cc
Compare
Summary
nvidia-nat-langchaincurrently declares every langchain provider integration as a required dependency:A consumer that only configures
_type: openai+_type: react_agent(the minimum to run a basic ReAct agent) still pulls all of them. That blows up wheel size, slows pip resolution, and -- most painfully -- transitivelangchain-aws/boto3/botocoreconstraints have been triggeringResolutionTooDeepfailures downstream that require manual pinning to work around.The good news: every provider module is already lazy-imported inside the matching
register_llm_client/register_functionbody, so the install-time deps were only nominally required. This PR promotes that reality into the package metadata.Dependency split
Core deps (always installed), matching what is actually imported at module load time:
langchain,langchain-classic,langchain-core,langgraphnvidia-nat-{core,eval,opentelemetry}pyopenssl(existing transitive pin)Optional extras (provider integrations):
[aws]langchain-aws[community]langchain-community,wikipedia[exa]langchain-exa[huggingface]langchain-huggingface[judge]openevals(LLM-as-judge eval)[litellm]langchain-litellm[milvus]langchain-milvus[nvidia]langchain-nvidia-ai-endpoints[oci]langchain-oci[openai]langchain-openai[tavily]langchain-tavily[all]Backwards compatibility
Both the top-level
nvidia-nat[langchain]andnvidia-nat[most]extras now resolve tonvidia-nat-langchain[all] == {version}, so anyone installing the toolkit via the umbrella distribution continues to get the exact same resolved tree as today. Only the barepip install nvidia-nat-langchaininstall surface shrinks; users who depend on a specific provider need to add the corresponding extra (e.g.pip install \"nvidia-nat-langchain[openai]\").uv.lockhas been regenerated against the new graph.Why this is safe today
A grep across
packages/nvidia_nat_langchain/src/confirms onlylangchain_core,langchain_classic, andlanggraphappear in top-levelfrom ... import ...statements. Every provider module (langchain_aws,langchain_openai,langchain_oci,langchain_huggingface,langchain_litellm,langchain_milvus,langchain_exa,langchain_tavily,langchain_community,langchain_nvidia_ai_endpoints) is imported lazily inside its registration function.openevalsis already wrapped in atry/except ImportErrorineval/langsmith_judge.py. So the split changes which depspipinstalls, not which code paths execute.Test plan
develop-targeted PR (existing tests should pass unchanged because[all]is installed in thetestextra)uv sync --extra langchain --extra mostresolves the same provider set as beforepip install "nvidia-nat-langchain[openai]"succeeds without pullinglangchain-aws/boto3pip install "nvidia-nat-langchain"is enough to importnat.plugins.langchainand use_type: react_agentSummary by CodeRabbit
New Features
Chores