cargo::ops

# Module resolve

source
Expand description

High-level APIs for executing the resolver.

This module provides functions for running the resolver given a workspace, including loading the `Cargo.lock` file and checkinf if it needs updating.

There are roughly 3 main functions:

- `resolve_ws`: A simple, high-level function with no options.
- `resolve_ws_with_opts`: A medium-level function with options like user-provided features. This is the most appropriate function to use in most cases.
- `resolve_with_previous`: A low-level function for running the resolver, providing the most power and flexibility.

#### §Data Structures

- `Workspace`: Usually created by `crate::util::command_prelude::ArgMatchesExt::workspace` which discovers the root of the workspace, and loads all the workspace members as a `Package` object
  - `Package` Corresponds with `Cargo.toml` manifest (deserialized as `Manifest`) and its associated files.
    - `Target`s are crates such as the library, binaries, integration test, or examples. They are what is actually compiled by `rustc`. Each `Target` defines a crate root, like `src/lib.rs` or `examples/foo.rs`.
    - `PackageId` — A unique identifier for a package.
- `PackageRegistry`: The primary interface for how the dependency resolver finds packages. It contains the `SourceMap`, and handles things like the `[patch]` table. The dependency resolver sends a query to the `PackageRegistry` to “get me all packages that match this dependency declaration”. The `Registry` trait provides a generic interface to the `PackageRegistry`, but this is only used for providing an alternate implementation of the `PackageRegistry` for testing.
- `SourceMap`: Map of all available sources.
  - `Source`: An abstraction for something that can fetch packages (a remote registry, a git repo, the local filesystem, etc.). Check out the source implementations for all the details about registries, indexes, git dependencies, etc.
    - `SourceId`: A unique identifier for a source.
  - `Summary`: A of a `Manifest`, and is essentially the information that can be found in a registry index. Queries against the `PackageRegistry` yields a `Summary`. The resolver uses the summary information to build the dependency graph.
- `PackageSet` — Contains all of the `Package` objects. This works with the `Downloads` struct to coordinate downloading packages. It has a reference to the `SourceMap` to get the `Source` objects which tell the `Downloads` struct which URLs to fetch.

## Structs§

- WorkspaceResolve
  Result for `resolve_ws_with_opts`.

## Constants§

- UNUSED_PATCH_WARNING 🔒

## Functions§

- add_overrides
  Read the `paths` configuration variable to discover all path overrides that have been configured.
- emit_warnings_of_unused_patches 🔒
  Emits warnings of unused patches case by case.
- get_resolved_packages
- lock_replacements 🔒
  Locks each `[replace]` entry to a specific Package ID if the lockfile contains any corresponding previous replacement.
- master_branch_git_source 🔒
- register_patch_entries 🔒
  Informs `registry` and `version_pref` that `[patch]` entries are available and preferable for the dependency resolution.
- register_previous_locks 🔒
  In this function we’re responsible for informing the `registry` of all locked dependencies from the previous lock file we had, `resolve`.
- resolve_with_previous
  Resolves all dependencies for a package using an optional previous instance of resolve to guide the resolution process.
- resolve_with_registry 🔒
- resolve_ws
  Resolves all dependencies for the workspace using the previous lock file as a guide if present.
- resolve_ws_with_opts
  Resolves dependencies for some packages of the workspace, taking into account `paths` overrides and activated features.

## Type Aliases§

- Keep 🔒
  Filter for keep using Package ID from previous lockfile.