A spike served a Cargo registry from dev.knotless.release records: a throwaway server, real cargo 1.98 and the reference PDS. Publish, login, yank, search, install, dependencies across repositories and a crate split over blobs all worked, and it left these to resolve. Each is to be ticked with the pull that settles it.
To do with the registry's build:
A duplicate version's error. The reference PDS answers a create of a record that exists with a plain 500, racing or not. Re-read the record to say published already, rather than taking any failed write to mean that, as Target::create does now.
Versions differing only in build metadata.1.0.0 and 1.0.0+b have different record keys, and Cargo's index may hold only one of them. A check before publishing stops all but a race. In a race the index keeps the oldest, and the publish that lost must not be told it succeeded.
A crate's description. The spike put it in notes, which holds release notes. Give it a place of its own.
Where the index line lives. As a blob it costs an upload per publish and a read per version on a cold index. Keep it in the record, as a new optional field.
The index after a publish. With an index a minute stale, cargo publish waited 61s and warned. A publish must update what serve answers at once, however serve's index gets the record.
The registry's URL. Cargo keeps it in Cargo.lock and in cross-repository dependencies, so use /cargo/<did>/<repo key>/, not names that can change. A rename was not tried.
To do apart from it:
Blob types on a stock PDS. The reference PDS recorded a .crate's first blob as application/gzip, where the lexicon accepts only application/octet-stream. On a PDS that looks at the bytes, other gzip release files probably get the same. The lexicon validator passes it, so nothing notices. See who reads the type, then widen the schema or say why it does not matter.
Not tried at all: real serve, a remote PDS, takedowns, the releases page, knotless release list and download over these records, and private crates. Yanking comes first, in a pull of its own.
The registry landed in ff044bc9, "knotless-serve answers Cargo's registry for a repository's crates", with the build items above. Only the blob types item is left open.
chadtmiller.com/knotless
What happened
A spike served a Cargo registry from
dev.knotless.releaserecords: a throwaway server, real cargo 1.98 and the reference PDS. Publish, login, yank, search, install, dependencies across repositories and a crate split over blobs all worked, and it left these to resolve. Each is to be ticked with the pull that settles it.To do with the registry's build:
published already, rather than taking any failed write to mean that, asTarget::createdoes now.1.0.0and1.0.0+bhave different record keys, and Cargo's index may hold only one of them. A check before publishing stops all but a race. In a race the index keeps the oldest, and the publish that lost must not be told it succeeded.notes, which holds release notes. Give it a place of its own.cargo publishwaited 61s and warned. A publish must update what serve answers at once, however serve's index gets the record.Cargo.lockand in cross-repository dependencies, so use/cargo/<did>/<repo key>/, not names that can change. A rename was not tried.To do apart from it:
.crate's first blob asapplication/gzip, where the lexicon accepts onlyapplication/octet-stream. On a PDS that looks at the bytes, other gzip release files probably get the same. The lexicon validator passes it, so nothing notices. See who reads the type, then widen the schema or say why it does not matter.Not tried at all: real serve, a remote PDS, takedowns, the releases page,
knotless release listanddownloadover these records, and private crates. Yanking comes first, in a pull of its own.The registry landed in ff044bc9, "knotless-serve answers Cargo's registry for a repository's crates", with the build items above. Only the blob types item is left open.