mirror of
https://github.com/hwchase17/langchain.git
synced 2026-07-01 14:47:02 +00:00
948f6cc58c
Following on the heels of #35293 TODO: - Packages outside of this repo (e.g. LiteLLM, Nvidia, Google, AWS) --- ## Summary Surface partner package versions in `metadata.versions` on LangSmith traces. Mirrors the JS SDK's `_addVersion()` pattern ([langchainjs#10106](https://github.com/langchain-ai/langchainjs/pull/10106)). Each model constructor records its package version via `_add_version()` on `BaseLanguageModel`. The version dict accumulates through the class hierarchy — `langchain-core` is added in `BaseLanguageModel.model_post_init`, `langchain-openai` in `BaseChatOpenAI._set_openai_chat_version`, and each leaf partner in its uniquely-named `model_validator`. Traces end up with: ```json { "metadata": { "versions": { "langchain-core": "1.4.5", "langchain-openai": "1.3.0", "langchain-xai": "1.2.2" } } } ``` ### Changes - `BaseLanguageModel._add_version(pkg, version)` — appends to `self.metadata["versions"]`; accepts any `Mapping` type; emits a warning if a non-mapping value is found and replaced - `BaseLanguageModel.model_post_init` — adds `langchain-core` version; calls `super()` for MRO safety - `_merge_metadata_dicts` — one-level-deep (non-recursive) merge for nested dict metadata keys - `CallbackManager.add_metadata` — uses `_merge_metadata_dicts` instead of flat `dict.update()` so nested metadata dicts (like `versions`) coexist rather than clobber - `merge_configs` — uses `_merge_metadata_dicts` for config merging **Partners:** - Each now calls `self._add_version("langchain-<pkg>", __version__)` ### Design decisions - **Constructor-based, not `_get_ls_params`-based** — versions flow through `self.metadata` (local metadata on traces), not through `LangSmithParams`. This matches JS and makes child-class version inheritance automatic (no merge/clobber issues). - **`versions` is local (non-inheritable) metadata** — `self.metadata` is passed to `CallbackManager.configure` as `local_metadata` (`add_metadata(..., inherit=False)`), so `versions` is attached **once per chat-model run** and is **not** propagated to child runs or duplicated onto every streaming chunk. This is intentionally the opposite of the inheritable-per-chunk metadata that #36588 was reducing for performance — `versions` does not regress that path. - **`add_metadata` deep-merge is a correctness fix, not just for versions** — previously `add_metadata`/`merge_configs` did a flat top-level `dict.update`/spread, so any nested metadata dict baked into a config (e.g. via `.with_config({"metadata": {...}})`) would be wholly replaced when a caller also passed `metadata`. `_merge_metadata_dicts` merges one level deep so user-provided `config.metadata.versions` and model-set `versions` coexist instead of clobbering. The merge runs once per `configure` (not per chunk), so it is off the streaming hot path. - **One level deep only** — `_merge_metadata_dicts` is deliberately *not* a recursive deep merge; values nested more than one level are last-writer-wins. This covers the `versions` case without the ambiguity/cost of arbitrary-depth merging. - **Warn on non-dict `metadata["versions"]`** — if a user sets `metadata={"versions": "some-string"}`, `_add_version` emits a warning and replaces the value with the version dict rather than silently discarding user data or crashing. This is a soft breaking change for anyone who previously stored non-dict values at this key. ### Follow-ups (tracked separately, out of scope here) - JS `mergeConfigs` still flat-spreads nested metadata, so `metadata.versions` can still clobber on the JS side until an equivalent deep-merge lands. --- Made by [Open SWE](https://openswe.vercel.app) --------- Co-authored-by: open-swe[bot] <open-swe@users.noreply.github.com>
🦜🍎️ LangChain Core
Looking for the JS/TS version? Check out LangChain.js.
To help you ship LangChain apps to production faster, check out LangSmith. LangSmith is a unified developer platform for building, testing, and monitoring LLM applications.
Quick Install
pip install langchain-core
🤔 What is this?
LangChain Core contains the base abstractions that power the LangChain ecosystem.
These abstractions are designed to be as modular and simple as possible.
The benefit of having these abstractions is that any provider can implement the required interface and then easily be used in the rest of the LangChain ecosystem.
⛰️ Why build on top of LangChain Core?
The LangChain ecosystem is built on top of langchain-core. Some of the benefits:
- Modularity: We've designed Core around abstractions that are independent of each other, and not tied to any specific model provider.
- Stability: We are committed to a stable versioning scheme, and will communicate any breaking changes with advance notice and version bumps.
- Battle-tested: Core components have the largest install base in the LLM ecosystem, and are used in production by many companies.
📖 Documentation
For full documentation, see the API reference. For conceptual guides, tutorials, and examples on using LangChain, see the LangChain Docs. You can also chat with the docs using Chat LangChain.
📕 Releases & Versioning
See our Releases and Versioning policies.
💁 Contributing
As an open-source project in a rapidly developing field, we are extremely open to contributions, whether it be in the form of a new feature, improved infrastructure, or better documentation.
For detailed information on how to contribute, see the Contributing Guide.