## Summary
Adds native uv workspace/lockfile support to the LangGraph CLI's Docker
build pipeline. Instead of listing dependencies manually, users can
point at their existing `uv.lock` and the CLI will:
1. Discover workspace packages and their dependency graph
2. Export locked requirements via `uv export --package <name> --frozen`
3. Copy only the necessary workspace closure into the container
4. Install packages in dependency order with `--no-deps` for
reproducibility
5. Rewrite all import paths (graphs, auth, encryption, etc.) to
container paths
### New config field: `source`
Rather than using `pip` or `uv pip`, we add a new `uv_lock` installer.
The previous installers should still remain unchanged.
To avoid ambiguity, we discriminate by "source" field and **do not
permit** other arbitrary "dependencies". In this mode, we will treat the
provided root (defaults to the current directory) as the source of
truth.
This also would natively support uv workspaces, so you can specify the
target package within a larger workspace.
**Simple single-package project:**
```json
{
"python_version": "3.11",
"graphs": {
"agent": "./agent.py:graph"
},
"source": {
"kind": "uv"
}
}
```
**Multi-package workspace with explicit package:**
```json
{
"python_version": "3.11",
"graphs": {
"agent": "../../apps/agent/src/agent/graph.py:graph"
},
"source": {
"kind": "uv",
"root": "../..",
"package": "agent"
}
}
```
**Traditional pip deployment (unchanged):**
```json
{
"python_version": "3.11",
"dependencies": ["langgraph", "my-package"],
"graphs": {
"agent": "./agent.py:graph"
}
}
```
Config validation enforces mutual exclusivity. you must use either
`dependencies` or `source`, not both.
---------
Co-authored-by: Will Fu-Hinthorn <will@langchain.dev>
Allow users to deploy to langsmith deployments from the langgraph-cli.
This PR makes the following changes:
1. Add a simple host backend client with httpx
2. Adjust `progress.py` to show elapsed time for commands, and also use
threading.Event to stop the spinner
3. Adjust `_build` to allow arbitrary command so we can pass `docker
buildx build` and default to `docker build`
4. Add new `deploy` command, this re-uses a lot of the `langgraph build`
functionality, and then uses the new host-backend client to push the
built image to langsmith deployments.
---------
Co-authored-by: David Asamu <david.asamu@langchain.dev>
* catching error thrown by asyncio
* using 2nd check for annotations given Pydantic 2.12 changes
* skipping tests for remote graph bc langgraph-api is dependent on
`jsonschema-rs`
* skipping tests w/ pydantic v1 models
```bash
hint: This usually indicates a problem with the package or the build environment.
help: `jsonschema-rs` (v0.29.1) was included because `langgraph:dev` (v1.0.0rc1) depends on `langgraph-cli[inmem]` which
depends on `langgraph-api` (v0.4.29) which depends on `jsonschema-rs`
```
not yet testing for free threaded python, that'll be much more involved!
ended up separating lint / testing deps during this process bc I was
getting a ton of not required deps while testing that were complicating
things :/
* Migrate to `uv`
* Format `pyproject.toml` files properly
* Remove upper bounds on dependencies, and bounds on dev dependencies
(we should be using latest)
* Move to hatch for packaing
In the future we should:
* Set up dependabot / automate lockfile updates and tests
* Add tests for min compatible versions (I'll do this right after merge)
* Use dynamic versioning
* Bump `pydantic` to v2.11.4 in the lockfile, we have some tests failing
Using this argument, you can get more customization since you can do
`langgraph build` or directly `docker build` your image and then re-use
the `langgraph up --image my-image` and have it also spin up redis &
postgres for you.
Easier then writing your own compose file
