Registries and mirrors

A dependency comes from futureblitz.dev’s registry unless it says otherwise. project.toml’s [registries] names others, each by its index.

Another registry

[registries]
company = { index = "https://packages.example.com/index/" }

[dependencies]
colors = "1.4"
tools = { version = "2", registry = "company" }

colors comes from futureblitz.dev, and tools from the company’s registry. The commands that talk to a registry take its name: fb add tools --registry company, fb publish --registry company, and fb login --registry company, whose token fb keeps apart from futureblitz.dev’s.

A package on another registry can depend on that registry’s packages, and on futureblitz.dev’s. Packages on futureblitz.dev depend only on its own.

A mirror

A [registries] entry named futureblitz replaces futureblitz.dev’s own index, for a mirror that serves the same files, as behind a company’s firewall:

[registries]
futureblitz = { index = "https://mirror.example.com/futureblitz/index/" }

The mirror serves each index file and archive as the registry does; fb checks every archive’s SHA-256 against fb.lock, so a mirror can’t change what a program builds.

A registry on disk

An index can be a folder, from project.toml’s: the same files the registry serves, config.json and one file a package, with config.json’s dl a template of a folder, or of a file:// URL. fb publish and fb yank write to it directly, which suits tests and machines with no network.

[registries]
local = { index = "../registry/index" }

What an index can be

• an https:// URL;
• an http:// URL on this machine only: localhost, a name under it, 127.0.0.1, or [::1];
• a folder, or a file:// URL.

The index describes the files a registry serves.