fb.lock

fb.lock, beside project.toml, records the exact version of each registry package a program builds with, and the hash of each archive, so every machine builds the same code. fb writes it; commit it with the program.

# fb.lock: the exact versions this package builds with, which fb writes. Don't edit it.
version = 1

[[package]]
name = "colors"
version = "1.4.2"
source = "https://index.futureblitz.dev/"
checksum = "sha256:9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08"
dependencies = ["palette"]
targets = { windows-x64 = "sha256:...", linux-x64 = "sha256:..." }

What’s in it

There’s one [[package]] for each registry package in the program, its dependencies’ too:

A local package, a path dependency, isn’t in it, but its own registry dependencies are.

When it changes

• A build reads fb.lock, and changes it only when project.toml asks for what it doesn’t have: a new dependency, a range the locked version is outside, or another registry. Then fb resolves again, keeping every locked version it can, and says what it added or changed.
• fb add adds the new package and what it needs, and changes nothing else.
• fb update resolves every version again, from the newest the ranges allow, or only those of the packages it’s given and what they need.

A download whose SHA-256 isn’t fb.lock’s is an error that names the package and both hashes, and nothing of it is used.

The cache

fb keeps what it downloads in a folder for each user, ~/.futureblitz/ (%USERPROFILE%\.futureblitz\ on Windows), or the folder FB_HOME names. A build finds each package through fb.lock alone, in the cache: fb check, build, run, test, doc, and publish download what fb.lock needs first. With --offline, or when the registry can’t be reached, fb uses only what’s in the cache, and says so.