Overview of LangChain v0.2
Source: langchain

---sidebar_position: 0sidebar_label: Overview of v0.2---# Overview of LangChain v0.2## 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](https://python.langchain.com/docs/expression_language/streaming/#using-stream-events).- [Standardized tool calling support](https://blog.langchain.dev/tool-calling-with-langchain/)- A standardized interface for [structuring output](https://github.com/langchain-ai/langchain/discussions/18154)- [@chain decorator](https://python.langchain.com/docs/expression_language/how_to/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](https://github.com/cbornet)!!)- Include response metadata in `AIMessage` to make it easy to access raw output from the underlying models- Tooling to visualize [your runnables](https://python.langchain.com/docs/expression_language/how_to/inspect/) or [your langgraph app](https://github.com/langchain-ai/langgraph/blob/main/examples/visualization.ipynb)- Interoperability of chat message histories across most providers- [Over 20+ partner packages in python](https://python.langchain.com/docs/integrations/platforms/) for popular integrations## What’s coming to LangChain?- We’ve been working hard on [langgraph](https://langchain-ai.github.io/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](https://github.com/langchain-ai/langchain/discussions/19339), 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` on `langchain-community`.- `langchain` package no longer requires `langchain-community` . Instead `langchain-community` will now depend on `langchain-core` and `langchain` .- User code that still relies on deprecated imports from `langchain` will continue to work as long `langchain_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](https://blog.langchain.dev/langchain-v0-1-0/).### Ecosystem organizationBy 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](https://blog.langchain.dev/tool-calling-with-langchain/).- **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:1. `langchain` is fairly lightweight. Here is the full list of required dependencies (after the split)    ```toml    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"    ```2. `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](https://github.com/langchain-ai/langchain/discussions/19083) of `langchain`.For more context about the reason for the organization please see our blog: https://blog.langchain.dev/langchain-v0-1-0/