Module index

Management of the index of a registry source.

This module contains management of the index and various operations, such as actually parsing the index, looking for crates, etc. This is intended to be abstract over remote indices (downloaded via Git or HTTP) and local registry indices (which are all just present on the filesystem).

How the index works

Here is a simple flow when loading a Summary (metadata) from the index:

1. A query is fired via RegistryIndex::query_inner.
2. Tries loading all summaries via RegistryIndex::load_summaries, and under the hood calling Summaries::parse to parse an index file.
   1. If an on-disk index cache is present, loads it via Summaries::parse_cache.
   2. Otherwise goes to the slower path RegistryData::load to get the specific index file.
3. A Summary is now ready in callback f in RegistryIndex::query_inner.

To learn the rationale behind this multi-layer index metadata loading, see the documentation of the on-disk index cache.

Modules

• cache 🔒
  A layer of on-disk index cache for performance.

Structs

• IndexPackage
  A single line in the index representing a single version of a package.
• RegistryDependency
  A dependency as encoded in the IndexPackage index JSON.
• RegistryIndex
  Manager for handling the on-disk index.
• Summaries 🔒
  An internal cache of summaries for a particular package.

Enums

• IndexSummary
  A parsed representation of a summary from the index. This is usually parsed from a line from a raw index file, or a JSON blob from on-disk index cache.
• MaybeIndexSummary 🔒
  A lazily parsed IndexSummary.

Constants

• INDEX_V_MAX 🔒
  The maximum schema version of the v field in the index this version of cargo understands. See IndexPackage::v for the detail.

Functions

• split 🔒
  Like slice::split but is optimized by [memchr].