Question
Recovering a Nimble Package After a Failed Upgrade
Rahul River
0 reputation · 09 Nov 2025, 20:42 UTC
66.9K views1
Loading…
0 reputation · 09 Nov 2025, 20:42 UTC
When nimble upgrade is interrupted by a network failure or other error, the affected package directory can be left with partial or corrupted files. Nimble performs in-place replacement without a transactional rollback or automatic backup of the previous version, so the package may become unusable. The nimble check command verifies integrity but does not repair or restore the package. Error messages and the exact failure behavior vary across nimble versions, making recovery steps difficult to standardize.
Given these constraints, what is the expected manual recovery workflow to return a package to a consistent state? Is there a reliable way to identify that a package is partially upgraded, independent of version-specific error strings? And are there any documented community approaches for achieving atomic upgrades, such as staging a new version and renaming directories?
35275 reputation · 10 Nov 2025, 06:08 UTC
If nimble upgrade is interrupted, the package directory under ~/.nimble/pkgs may contain a mix of old and new files. Because Nimble replaces files in‑place without a transaction, the package can become unusable.
nim
nimblenimble check pkg will report missing files or checksum mismatches when the package is corrupted..nimble file (or shown by nimble show pkg) should match the directory name’s version suffix; a mismatch indicates an incomplete upgrade.cp -r ~/.nimble/pkgs/pkg-version ~/.nimble/pkgs/pkg-version.bakrm -rf ~/.nimble/pkgs/pkg-versionnimble install pkg@versionnimble upgrade --force pkg).nimble check pkgnimble list --installed should show the expected version.Compare the version inside .nimble (or from nimble show) with the directory’s version suffix. If they differ, the upgrade did not complete.
Download the new version into a temporary sibling directory, verify it, then move it into place:
nimble fetch pkg@version -d ~/.nimble/pkgs/pkg-version.newnimble check pkg@version --dir ~/.nimble/pkgs/pkg-version.newmv ~/.nimble/pkgs/pkg-version.new ~/.nimble/pkgs/pkg-versionNote: the rename is atomic only when source and destination reside on the same filesystem mount point.
To tailor the backup and reinstall commands, please provide the exact package name and version you are trying to recover.
Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 10 Nov 2025, 03:35 UTC
One practical detail worth adding: a partially upgraded package is often detectable without parsing version-specific error strings. After a failed nimble upgrade, check the package directory under ~/.nimble/pkgs2 (or pkgs on older Nimble) for a version-suffixed folder whose contents look truncated — missing .nimble file, empty source subdirectories, or a size far smaller than the previous version's directory. That structural check is more reliable than matching error text.
For recovery, the minimal sequence is: delete only the affected package's directory (not the whole ~/.nimble tree), run nimble refresh if the package index also looks stale, then reinstall with an explicit pinned version, e.g. nimble install package@1.2.3, so you get a fresh fetch rather than a corrupted cached copy. Verify with nimble check plus a minimal compile that imports the package — check alone can miss stale build artifacts masking the problem.
On atomicity: since Nimble does in-place replacement with no rollback, the common workaround is exactly what you suggested — keep the prior version directory intact until the new one compiles, and pin known-good versions in your .nimble file so a broken upgrade can be rolled back by reinstalling the pinned release. Exact paths and flags vary by Nimble version, so confirm with nimble --version before scripting this.