Skip to content

docs: add lock file section to the resolver docs #15587

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

docs: add lock file section to the resolver docs #15587

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 19 additions & 0 deletions src/doc/src/reference/resolver.md
View file
Open in desktop
Copy link
Member

@weihanglo weihanglo May 23, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps instead, we can just talk about the property of a single view of dependency resolution, so that we don't repeat ourselves and still provide what you originally wanted to know.

### Single view of dependency resolution

When building a package or a workspace, Cargo computes a single,
unified resolution of all dependencies across the entire dependency graph.
This maximizes the reuse of package versions within the resolution process.
Unlike some other package managers, Cargo does not use Cargo.lock files
from dependencies or perform per-dependency resolution.
All resolution is done from the root.

Original file line number Diff line number Diff line change
Expand Up @@ -12,6 +12,25 @@ resolver.
[dependency specification]: specifying-dependencies.md
[`cargo tree`]: ../commands/cargo-tree.md

## `Cargo.lock` lock-files

The `Cargo.lock` file provides deterministic builds at different times and on
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are some other places the book mentions Cargo.lock

it is a bit duplicate everywhere. We might want some level of consolidation.

different systems, by ensuring that the exact same dependencies, versions, and
sources are used as when the `Cargo.lock` file was last generated.
Dependancy resolution is not run when cargo reads from `Cargo.lock`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is incorrect. Cargo always performs dependency resolutions and prefers to versions tracked in Cargo.lock.


Not all cargo commands use `Cargo.lock` by default. Examples include
`cargo install` and `cargo update`.In these cases, `--locked` can usually be
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a bit off. cargo update would always consult the existing Cargo.lock, especially when doing a partial update.

passed to force cargo to use the dependency graph from an existing `Cargo.lock`
(if one exists).

### Libraries with `Cargo.lock`

Cargo treats `Cargo.lock` files differently when a crate is used as a library
dependency where an upper level `Cargo.lock` would exist. In these cases cargo will
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Upper-level / top-level is pretty vague here. Cargo actually ignores any lockfile but the one at the workspace root.

not inspect the dependency's `Cargo.lock` even if it exists, using only the
top-level `Cargo.lock`.

## Constraints and Heuristics

In many cases there is no single "best" dependency resolution.
Expand Down