Setup
This guide walks through how to run the repository locally and check in your first code. For a development container, see the .devcontainer folder.
Dependency management: uv
and other env/dependency managers
This project utilizes uv v0.5+ as a dependency manager.
Install uv
: documentation on how to install it.
Windows Users
If you're on Windows and don't have make
installed, you can install it via:
- Option 1: Install via Chocolatey:
choco install make
- Option 2: Install via Scoop:
scoop install make
- Option 3: Use Windows Subsystem for Linux (WSL)
- Option 4: Use the direct
uv
commands shown in the sections below
Different packages
This repository contains multiple packages:
langchain-core
: Base interfaces for key abstractions as well as logic for combining them in chains (LangChain Expression Language).langchain
: Chains, agents, and retrieval logic that makes up the cognitive architecture of your applications.- Partner integrations: Partner packages in
libs/partners
that are independently version controlled.
Some LangChain packages live outside the monorepo, see for example langchain-community for various third-party integrations and langchain-experimental for abstractions that are experimental (either in the sense that the techniques are novel and still being tested, or they require giving the LLM more access than would be possible in most production systems).
Each of these has its own development environment. Docs are run from the top-level makefile, but development is split across separate test & release flows.
For this quickstart, start with langchain
:
cd libs/langchain
Local development dependencies
Install development requirements (for running langchain, running examples, linting, formatting, tests, and coverage):
uv sync
Then verify dependency installation:
# If you have `make` installed:
make test
# If you don't have `make` (Windows alternative):
uv run --group test pytest -n auto --disable-socket --allow-unix-socket tests/unit_tests
Testing
Note: In langchain
, langchain-community
, and langchain-experimental
, some test dependencies are optional. See the following section about optional dependencies.
Unit tests cover modular logic that does not require calls to outside APIs. If you add new logic, please add a unit test.
To run unit tests:
# If you have `make` installed:
make test
# If you don't have make (Windows alternative):
uv run --group test pytest -n auto --disable-socket --allow-unix-socket tests/unit_tests
There are also integration tests and code-coverage available.
Developing langchain_core
If you are only developing langchain_core
, you can simply install the dependencies for the project and run tests:
cd libs/core
# If you have `make` installed:
make test
# If you don't have `make` (Windows alternative):
uv run --group test pytest -n auto --disable-socket --allow-unix-socket tests/unit_tests
Formatting and linting
Run these locally before submitting a PR; the CI system will check also.
Code formatting
Formatting for this project is done via ruff.
To run formatting for docs, cookbook and templates:
# If you have `make` installed:
make format
# If you don't have make (Windows alternative):
uv run --all-groups ruff format .
uv run --all-groups ruff check --fix .
To run formatting for a library, run the same command from the relevant library directory:
cd libs/{LIBRARY}
# If you have `make` installed:
make format
# If you don't have make (Windows alternative):
uv run --all-groups ruff format .
uv run --all-groups ruff check --fix .
Additionally, you can run the formatter only on the files that have been modified in your current branch as compared to the master branch using the format_diff command:
# If you have `make` installed:
make format_diff
# If you don't have `make` (Windows alternative):
# First, get the list of modified files:
git diff --relative=libs/langchain --name-only --diff-filter=d master | grep -E '\.py$$|\.ipynb$$' | xargs uv run --all-groups ruff format
git diff --relative=libs/langchain --name-only --diff-filter=d master | grep -E '\.py$$|\.ipynb$$' | xargs uv run --all-groups ruff check --fix
This is especially useful when you have made changes to a subset of the project and want to ensure your changes are properly formatted without affecting the rest of the codebase.
Linting
Linting for this project is done via a combination of ruff and mypy.
To run linting for docs, cookbook and templates:
# If you have `make` installed:
make lint
# If you don't have `make` (Windows alternative):
uv run --all-groups ruff check .
uv run --all-groups ruff format . --diff
uv run --all-groups mypy . --cache-dir .mypy_cache
To run linting for a library, run the same command from the relevant library directory:
cd libs/{LIBRARY}
# If you have `make` installed:
make lint
# If you don't have `make` (Windows alternative):
uv run --all-groups ruff check .
uv run --all-groups ruff format . --diff
uv run --all-groups mypy . --cache-dir .mypy_cache
In addition, you can run the linter only on the files that have been modified in your current branch as compared to the master branch using the lint_diff command:
# If you have `make` installed:
make lint_diff
# If you don't have `make` (Windows alternative):
# First, get the list of modified files:
git diff --relative=libs/langchain --name-only --diff-filter=d master | grep -E '\.py$$|\.ipynb$$' | xargs uv run --all-groups ruff check
git diff --relative=libs/langchain --name-only --diff-filter=d master | grep -E '\.py$$|\.ipynb$$' | xargs uv run --all-groups ruff format --diff
git diff --relative=libs/langchain --name-only --diff-filter=d master | grep -E '\.py$$|\.ipynb$$' | xargs uv run --all-groups mypy --cache-dir .mypy_cache
This can be very helpful when you've made changes to only certain parts of the project and want to ensure your changes meet the linting standards without having to check the entire codebase.
We recognize linting can be annoying - if you do not want to do it, please contact a project maintainer, and they can help you with it. We do not want this to be a blocker for good code getting contributed.
Spellcheck
Spellchecking for this project is done via codespell.
Note that codespell
finds common typos, so it could have false-positive (correctly spelled but rarely used) and false-negatives (not finding misspelled) words.
To check spelling for this project:
# If you have `make` installed:
make spell_check
# If you don't have `make` (Windows alternative):
uv run --all-groups codespell --toml pyproject.toml
To fix spelling in place:
# If you have `make` installed:
make spell_fix
# If you don't have `make` (Windows alternative):
uv run --all-groups codespell --toml pyproject.toml -w
If codespell is incorrectly flagging a word, you can skip spellcheck for that word by adding it to the codespell config in the pyproject.toml
file.
[tool.codespell]
...
# Add here:
ignore-words-list = 'momento,collison,ned,foor,reworkd,parth,whats,aapply,mysogyny,unsecure'
Working with optional dependencies
langchain
, langchain-community
, and langchain-experimental
rely on optional dependencies to keep these packages lightweight.
langchain-core
and partner packages do not use optional dependencies in this way.
You'll notice that pyproject.toml
and uv.lock
are not touched when you add optional dependencies below.
If you're adding a new dependency to Langchain, assume that it will be an optional dependency, and that most users won't have it installed.
Users who do not have the dependency installed should be able to import your code without any side effects (no warnings, no errors, no exceptions).
To introduce the dependency to a library, please do the following:
- Open extended_testing_deps.txt and add the dependency
- Add a unit test that the very least attempts to import the new code. Ideally, the unit test makes use of lightweight fixtures to test the logic of the code.
- Please use the
@pytest.mark.requires(package_name)
decorator for any unit tests that require the dependency.
Adding a Jupyter Notebook
If you are adding a Jupyter Notebook example, you'll want to run with test
dependencies:
uv run --group test jupyter notebook
When you run uv sync
, the langchain
package is installed as editable in the virtualenv, so your new logic can be imported into the notebook.