Skip to content
Beskid The Beskid Book

Beskid

Jump to a Beskid service

Beskid

Jump to a Beskid service

03.4 Fetch, lock, update

Dependency resolution, Project.lock, frozen builds, and staying reproducible."

Fetch, lock, update

Manifests declare intent. Locks declare what actually happened—so CI and your laptop stop arguing.

CommandRole
fetchResolve and materialize dependencies into obj/beskid
lockSynchronize Project.lock with current resolution
updateRefresh resolution and materialized tree when policy allows

Reference: fetch, lock, update, lockfile guide.

CI should prefer reproducible resolution:

  • --frozen — fail if lock would change
  • --locked — enforce lock consistency (see per-command docs for exact semantics)
flowchart LR
  M[Project.proj] --> R[Resolver]
  R --> L[Project.lock]
  R --> O[obj/beskid materialized]
  L --> CI[CI with --frozen]

Expect Project.lock updates when:

  • You add/remove/retarget dependencies
  • Path dependencies move on disk (sometimes)
  • Resolver policy or toolchain version changes resolution

Do not .gitignore the lock because “it is generated” unless you enjoy production roulette.

With source = path as the enabled provider, “version drift” is often literally different folders on disk. Workspaces add shared override policy—chapter 06.

Tree and resolution