mirror of
https://github.com/rust-lang/cargo.git
synced 2025-10-01 11:30:39 +00:00
Auto merge of #11604 - pkgw:resolver-unification-docs, r=ehuss
book: describe how the current resolver sometimes duplicates deps ### What does this PR try to resolve? This updates the book to document the behavior described in #9029, where sometimes Cargo will duplicate a dep when it doesn't have to. ### How should we test and review this PR? Doc-only change; someone with knowledge of the resolver should read and assess.
This commit is contained in:
commit
4a2ebfbbf3
@ -7,8 +7,10 @@ result of the resolution is stored in the `Cargo.lock` file which "locks" the
|
|||||||
dependencies to specific versions, and keeps them fixed over time.
|
dependencies to specific versions, and keeps them fixed over time.
|
||||||
|
|
||||||
The resolver attempts to unify common dependencies while considering possibly
|
The resolver attempts to unify common dependencies while considering possibly
|
||||||
conflicting requirements. The sections below provide some details on how these
|
conflicting requirements. It turns out, however, that in many cases there is no
|
||||||
constraints are handled, and how to work with the resolver.
|
single "best" dependency resolution, and so the resolver must use heuristics to
|
||||||
|
choose a preferred solution. The sections below provide some details on how
|
||||||
|
requirements are handled, and how to work with the resolver.
|
||||||
|
|
||||||
See the chapter [Specifying Dependencies] for more details about how
|
See the chapter [Specifying Dependencies] for more details about how
|
||||||
dependency requirements are specified.
|
dependency requirements are specified.
|
||||||
@ -490,6 +492,35 @@ break the build.
|
|||||||
The following illustrates some problems you may experience, and some possible
|
The following illustrates some problems you may experience, and some possible
|
||||||
solutions.
|
solutions.
|
||||||
|
|
||||||
|
### Unexpected dependency duplication
|
||||||
|
|
||||||
|
The resolver algorithm may converge on a solution that includes two copies of a
|
||||||
|
dependency when one would suffice. For example:
|
||||||
|
|
||||||
|
```toml
|
||||||
|
# Package A
|
||||||
|
[dependencies]
|
||||||
|
rand = "0.7"
|
||||||
|
|
||||||
|
# Package B
|
||||||
|
[dependencies]
|
||||||
|
rand = ">=0.6" # note: open requirements such as this are discouraged
|
||||||
|
```
|
||||||
|
|
||||||
|
In this example, Cargo may build two copies of the `rand` crate, even though a
|
||||||
|
single copy at version `0.7.3` would meet all requirements. This is because the
|
||||||
|
resolver's algorithm favors building the latest available version of `rand` for
|
||||||
|
Package B, which is `0.8.5` at the time of this writing, and that is
|
||||||
|
incompatible with Package A's specification. The resolver's algorithm does not
|
||||||
|
currently attempt to "deduplicate" in this situation.
|
||||||
|
|
||||||
|
The use of open-ended version requirements like `>=0.6` is discouraged in Cargo.
|
||||||
|
But, if you run into this situation, the [`cargo update`] command with the
|
||||||
|
`--precise` flag can be used to manually remove such duplications.
|
||||||
|
|
||||||
|
[`cargo update`]: ../commands/cargo-update.md
|
||||||
|
|
||||||
|
|
||||||
### SemVer-breaking patch release breaks the build
|
### SemVer-breaking patch release breaks the build
|
||||||
|
|
||||||
Sometimes a project may inadvertently publish a point release with a
|
Sometimes a project may inadvertently publish a point release with a
|
||||||
|
Loading…
x
Reference in New Issue
Block a user