-
Type:
Task
-
Resolution: Fixed
-
Priority:
Unknown
-
Affects Version/s: None
-
Component/s: ABX
-
None
-
None
-
Python Drivers
-
Not Needed
-
-
None
-
None
-
None
-
None
-
None
-
None
Goal
Drop the langchain-mongodb dependency from langchain-mongodb-deepagents-vfs by importing text_search_stage from pymongo-search-utils, which the package already depends on.
Background
langchain-mongodb is used for exactly one thing — a single import at langchain_mongodb_deepagents_vfs/search.py:16:
from langchain_mongodb.pipelines import text_search_stage
used at one call site (search.py:332), in the no-vector fallback branch of _grep_hybrid.
The same file already imports the sibling function from the other package:
from pymongo_search_utils import vector_search_stage
So two closely related helpers are pulled from two different packages, and one of those packages exists in the dependency tree solely to supply it.
The two functions are equivalent
pymongo_search_utils.text_search_stage and langchain_mongodb.pipelines.text_search_stage are separate implementations, not a re-export. Diffing the source shows the only differences are typing syntax:
- search_field: Union[str, List[str]], + search_field: str | list[str], - limit: Optional[int] = None, + limit: int | None = None, -) -> List[Dict[str, Any]]: +) -> list[dict[str, Any]]:
Same parameters, same defaults, same emitted stages ($search -> optional $match -> optional $set score -> optional $limit). Behaviourally identical.
For contrast, vector_search_stage is literally the same object in both packages (langchain_mongodb re-exports it from pymongo_search_utils), which is why only text_search_stage needs attention.
No floor change needed
pymongo-search-utils is already declared at >=0.3.0, and text_search_stage has been present since 0.1.0 (verified by installing 0.1.0, 0.2.0 and 0.3.0 and checking for the attribute). The swap is safe at the existing floor.
Impact
Net packages removed from the dependency closure: 9.
async-timeout, greenlet, importlib-metadata, langchain-classic, langchain-mongodb, langchain-text-splitters, lark, numpy, sqlalchemy
Note this is the net figure. langchain-mongodb's full transitive closure is 50 packages, but most are reached anyway through deepagents (which pulls langchain, langchain-core, langsmith and their trees). The nine above are the ones reachable only via langchain-mongodb — numpy and sqlalchemy being the notable weight.
Secondary benefit: removes release-order coupling
While planning the first deepagents-vfs release we had to reason about whether it should ship before or after langchain-mongodb 0.12.0, because its langchain-mongodb>=0.11.0 floor would otherwise name a version predating the Python 3.14 dependency fixes (INTPYTHON-1054, INTPYTHON-1065). Removing the dependency removes that question permanently, and one fewer sibling floor to keep current.
Steps
- Change the import in search.py to from pymongo_search_utils import text_search_stage, alongside the existing vector_search_stage import.
- Remove "langchain-mongodb>=0.11.0" from dependencies in pyproject.toml; regenerate uv.lock.
- Re-verify the grep paths, in particular _grep_hybrid's no-vector fallback (the only caller) and the $rankFusion branch that neighbours it.
- Confirm the minimum-version suite still passes, since the resolved graph changes materially.
Acceptance criteria
- No import of langchain_mongodb anywhere in langchain_mongodb_deepagents_vfs/.
- langchain-mongodb absent from dependencies and from the resolved uv.lock closure.
- Unit and integration suites pass at both default and lowest-direct resolution.
- grep behaviour unchanged — same pipeline stages emitted in both the hybrid and fallback branches.
Notes
- Best done before the first release. The package is unpublished, so removing a dependency now costs nothing; afterwards it is a visible change to consumers' resolved environments.
- The package name langchain-mongodb-deepagents-vfs would no longer reflect a real dependency on langchain-mongodb. That is fine — it still implements the DeepAgents BackendProtocol against MongoDB — but worth being aware of.