Overview
What’s new in LangChain?​
The following features have been added during the development of 0.1.x:
- Better streaming support via the Event Streaming API.
- Standardized tool calling support
- A standardized interface for structuring output
- @chain decorator to more easily create RunnableLambdas
- https://python.langchain.com/docs/expression_language/how_to/inspect/
- In Python, better async support for many core abstractions (thank you @cbornet!!)
- Include response metadata in
AIMessage
to make it easy to access raw output from the underlying models - Tooling to visualize your runnables or your langgraph app
- Interoperability of chat message histories across most providers
- Over 20+ partner packages in python for popular integrations
What’s coming to LangChain?​
- We’ve been working hard on langgraph. We will be building more capabilities on top of it and focusing on making it the go-to framework for agent architectures.
- Vectorstores V2! We’ll be revisiting our vectorstores abstractions to help improve usability and reliability.
- Better documentation and versioned docs!
- We’re planning a breaking release (0.3.0) sometime between July-September to upgrade to full support of Pydantic 2, and will drop support for Pydantic 1 (including objects originating from the
v1
namespace of Pydantic 2).
What changed?​
Due to the rapidly evolving field, LangChain has also evolved rapidly.
This document serves to outline at a high level what has changed and why.
TLDR​
As of 0.2.0:
- This release completes the work that we started with release 0.1.0 by removing the dependency of
langchain
onlangchain-community
. langchain
package no longer requireslangchain-community
. Insteadlangchain-community
will now depend onlangchain-core
andlangchain
.- User code that still relies on deprecated imports from
langchain
will continue to work as longlangchain_community
is installed. These imports will start raising errors in release 0.4.x.
As of 0.1.0:
langchain
was split into the following component packages:langchain-core
,langchain
,langchain-community
,langchain-[partner]
to improve the usability of langchain code in production settings. You can read more about it on our blog.
Ecosystem organization​
By the release of 0.1.0, LangChain had grown to a large ecosystem with many integrations and a large community.
To improve the usability of LangChain in production, we split the single langchain
package into multiple packages. This allowed us to create a good foundation architecture for the LangChain ecosystem and improve the usability of langchain
in production.
Here is the high level break down of the Eco-system:
- langchain-core: contains core abstractions involving LangChain Runnables, tooling for observability, and base implementations of important abstractions (e.g., Chat Models).
- langchain: contains generic code that is built using interfaces defined in
langchain-core
. This package is for code that generalizes well across different implementations of specific interfaces. For example,create_tool_calling_agent
works across chat models that support tool calling capabilities. - langchain-community: community maintained 3rd party integrations. Contains integrations based on interfaces defined in langchain-core. Maintained by the LangChain community.
- Partner Packages (e.g., langchain-[partner]): Partner packages are packages dedicated to especially popular integrations (e.g.,
langchain-openai
,langchain-anthropic
etc.). The dedicated packages generally benefit from better reliability and support. langgraph
: Build robust and stateful multi-actor applications with LLMs by modeling steps as edges and nodes in a graph.langserve
: Deploy LangChain chains as REST APIs.
In the 0.1.0 release, langchain-community
was retained as required a dependency of langchain
.
This allowed imports of vectorstores, chat models, and other integrations to continue working through langchain
rather than forcing users to update all of their imports to langchain-community
.
For the 0.2.0 release, we’re removing the dependency of langchain
on langchain-community
. This is something we’ve been planning to do since the 0.1 release because we believe this is the right package architecture.
Old imports will continue to work as long as langchain-community
is installed. These imports will be removed in the 0.4.0 release.
To understand why we think breaking the dependency of langchain
on langchain-community
is best we should understand what each package is meant to do.
langchain
is meant to contain high-level chains and agent architectures. The logic in these should be specified at the level of abstractions like ChatModel
and Retriever
, and should not be specific to any one integration. This has two main benefits:
langchain
is fairly lightweight. Here is the full list of required dependencies (after the split)python = ">=3.8.1,<4.0"
langchain-core = "^0.2.0"
langchain-text-splitters = ">=0.0.1,<0.1"
langsmith = "^0.1.17"
pydantic = ">=1,<3"
SQLAlchemy = ">=1.4,<3"
requests = "^2"
PyYAML = ">=5.3"
numpy = "^1"
aiohttp = "^3.8.3"
tenacity = "^8.1.0"
jsonpatch = "^1.33"langchain
chains/agents are largely integration-agnostic, which makes it easy to experiment with different integrations and future-proofs your code should there be issues with one specific integration.
There is also a third less tangible benefit which is that being integration-agnostic forces us to find only those very generic abstractions and architectures which generalize well across integrations. Given how general the abilities of the foundational tech are, and how quickly the space is moving, having generic architectures is a good way of future-proofing your applications.
langchain-community
is intended to have all integration-specific components that are not yet being maintained in separate langchain-{partner}
packages. Today this is still the majority of integrations and a lot of code. This code is primarily contributed by the community, while langchain
is largely written by core maintainers. All of these integrations use optional dependencies and conditional imports, which prevents dependency bloat and conflicts but means compatible dependency versions are not made explicit. Given the volume of integrations in langchain-community
and the speed at which integrations change, it’s very hard to follow semver versioning, and we currently don’t.
All of which is to say that there’s no large benefits to langchain
depending on langchain-community
and some obvious downsides: the functionality in langchain
should be integration agnostic anyways, langchain-community
can’t be properly versioned, and depending on langchain-community
increases the vulnerability surface of langchain
.
For more context about the reason for the organization please see our blog: https://blog.langchain.dev/langchain-v0-1-0/