1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
//! Wire types for the toolchain lockfile (`zlayer-toolchains.lock`).
//!
//! These are **pure serde** shapes. The file's load/save/lookup/upsert I/O (TOML
//! on disk, deterministic ordering, sha256 recomputation) lives in
//! `zlayer-toolchain`'s `lockfile` module — this crate only defines the shapes so
//! both `zlayer-toolchain` (which *consumes* a lock during provisioning) and
//! `zlayer-builder` (which will *pass* one through in a later commit) can name
//! them without pulling in `tokio`/`reqwest`.
//!
//! A lock pins one resolved `(tool, platform, arch)` to an exact `version`,
//! download `url`, and `sha256`, so a later provision is reproducible and
//! integrity-checked rather than resolving "latest" afresh.
use ;
/// Current on-disk schema version for [`ToolchainLockfile`].
pub const TOOLCHAIN_LOCK_SCHEMA: u32 = 1;
/// The parsed toolchain lockfile: a schema tag, a generation timestamp, and the
/// set of pinned tools (serialized as a TOML `[[tool]]` array of tables).
/// One pinned toolchain entry: an exact, integrity-checked resolution.
///
/// `Ord` is derived field-by-field (tool, then platform, then arch, ...), so the
/// natural sort orders entries by `(tool, platform, arch)` first — the ordering
/// the lockfile writer uses for a stable, diff-friendly file.