nimble.lock in Library Repositories: Should the Lock File Be Committed After Upgrading to a Nimble Version That Supports It?

Question

Our Nim project recently moved to a toolchain whose Nimble version supports the nimble lock command and honors nimble.lock during nimble install. The repository is a library published to the Nimble package list, not a deployable application, and we need to decide whether the lock file belongs in version control.

The tension we see: committing nimble.lock pins exact dependency versions and VCS revisions, which makes CI runs and contributor checkouts reproducible. But the same pinning could mask compatibility drift, since our declared version ranges in the .nimble file would keep resolving against old locked revisions while downstream users get whatever the solver picks fresh. Deleting the lock before release testing is one option, but that reintroduces non-determinism into the exact pipeline we wanted to stabilize.

We have not found documented guidance in Nimble itself distinguishing library versus application lock-file policy, and solver behavior has changed across releases, so we want to pin this down for our specific Nimble version.

Is committing nimble.lock in a published library repository considered harmful for downstream resolution, or does Nimble ignore a dependency's own lock file when it is consumed as a package?
If the lock is committed, what is the recommended workflow for periodically testing against the newest allowed dependency versions within our declared ranges?
Does the answer change if the same repository also ships a binary built via a Nimble task?

Tasadduq Burney · Answer

Answer
If you are using a Nimble version that supports lock files (≥0.10.0), you can safely commit nimble.lock in a library repository. The lock file only influences builds where the repository is the root project; downstream consumers ignore it, so committing it does not affect their dependency resolution.
Confirmed facts

Nimble loads and honors the lock file only from the current project’s directory; it does not recurse into dependencies.
Therefore a library’s nimble.lock is ignored when that library is fetched as a dependency by another project.
The behavior has been stable since lock‑file support was introduced (around Nimble 0.10.0) and has not changed in later releases.

Recommended workflow

Commit the initial nimble.lock generated by nimble lock.
In CI or local builds, rely on the lock file for reproducible installs.
Periodically update the lock to test against the newest allowed versions:
nimble lock   # or nimble develop --update
git add nimble.lock
git commit -m "Update lock file to latest compatible versions"

Run your test suite after the update; if it passes, keep the new lock; otherwise adjust version constraints in .nimble.
Optionally automate this with a scheduled job or a pre‑release step that updates the lock before publishing a new version.

Effect of also shipping a binary
The same rule applies: the lock file influences only the binary build when the repository is the root project. Consumers of the library still ignore the lock file, so committing it does not harm downstream resolution.
Missing diagnostic detail
To confirm that the above applies to your setup, please tell us the exact Nimble version you are using (output of nimble -v). If your version is older than 0.10.0, lock‑file support is absent and committing nimble.lock would be ignored or could cause errors.

nimble.lock in Library Repositories: Should the Lock File Be Committed After Upgrading to a Nimble Version That Supports It?

1 answer

Answer

Confirmed facts

Recommended workflow

Effect of also shipping a binary

Missing diagnostic detail

Your perspective belongs here.

0 question comments