Expand description
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:
- A query is fired via
RegistryIndex::query_inner
. - Tries loading all summaries via
RegistryIndex::load_summaries
, and under the hood callingSummaries::parse
to parse an index file.- If an on-disk index cache is present, loads it via
Summaries::parse_cache
. - Otherwise goes to the slower path
RegistryData::load
to get the specific index file.
- If an on-disk index cache is present, loads it via
- A
Summary
is now ready in callbackf
inRegistryIndex::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§
- A single line in the index representing a single version of a package.
- A dependency as encoded in the
IndexPackage
index JSON. - Manager for handling the on-disk index.
- An internal cache of summaries for a particular package.
Enums§
- 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.
- A lazily parsed
IndexSummary
.
Constants§
- The maximum schema version of the
v
field in the index this version of cargo understands. SeeIndexPackage::v
for the detail.
Functions§
- split 🔒Like
slice::split
but is optimized by [memchr
].