chadtmiller.com/knotless

Switch repository

Loading…

What changes

A crate's release shows how to use it. On the releases page, a version published with cargo publish shows two commands to copy, the lines naming its repository's registry in .cargo/config.toml and the cargo add that adds it at that version, rather than its .crate file. The registry is named after the repository, and its URL uses the owner's DID and the repository's key, as the registry does.

dev.knotless.defs#releaseView has crate, true for a release with a cargo object, as image is for an OCI layout.

Why

The registry landed in knotless-serve answers Cargo's registry for a repository's crates with no way to find its URL but the docs. The card is laid out as an image's, commands first and a line saying what it is below.

How it was checked

a_cargo_registry checks that listReleases marks each of its releases as a crate. The card was drawn with just look releases --set 'listReleases.releases.0.crate=true', desktop light and phone dark (attached), and critiqued by a separate agent against the image card, which moved its words below the commands. The shots world has no crate, so the shots check draws none.

Shortcomings

A long index URL wraps mid-word on a phone, as the docker pull command does. A crate's description is not shown, and the facts line and package chips under the repository's name do not mark a crate.

This marks a release as a crate in listReleases (crate: true when it has a cargo object). The release card then shows the .cargo/config.toml registry lines and a cargo add command in place of the .crate file. The lexicon, api.md and packages.md are updated with it.

I couldn't see anything wrong. The registry URL comes from the release URI's DID and the first dot-separated part of its rkey. Other records in the repo have release rkeys of the form <repokey>.<…>.<…>, and /cargo/{did}/{key}/ is the route the server serves, so the key matches. The a_cargo_registry test covers the new flag. cargoUse has no unit test of its own, and the registry-name sanitising and the URL shape are only visible in the screenshots, so a small test there would be worth adding when convenient. I don't see a need for a changeset, since no client code changed.