pantry install resolves every system dependency against the registry, even when pantry.lock already pins a version that satisfies the declared range. A plain install rewrites the pin to the newest matching release. --frozen-lockfile installs that newest release into pantry/ and only then fails. So a committed lock never fixes what gets installed, and any upstream release inside a declared range turns a frozen CI run red without a change in the project.
Reproduction (pantry 0.11.144, macOS arm64; 0.11.145 has no resolver changes)
mkdir lock-pin && cd lock-pin
echo '{ "name": "lock-pin", "version": "0.0.0", "system": { "sqlite.org": "^3.53.4" } }' > package.json
pantry install --ignore-scripts # writes pantry.lock with sqlite.org@3.54.1Edit pantry.lock so its sqlite.org entry is sqlite.org@3.53.4 (key, version and resolved). 3.53.4 satisfies ^3.53.4, so a lockfile should keep it. Then, starting from an empty pantry/:
| Command | Exit | Installed | pantry.lock |
|---|---|---|---|
pantry install --ignore-scripts | 0 | sqlite.org/v3.54.1 | rewritten: pantry.lock: sqlite.org 3.53.4 -> 3.54.1 |
pantry install --frozen-lockfile --ignore-scripts | 1, lockfile is out of date (--frozen-lockfile) | sqlite.org/v3.54.1 | untouched |
Control: with the lock pinned to the newest version (3.54.1), the frozen install exits 0 ("4 packages up to date") and leaves the lock byte-identical. Declaring a new dependency (curl.se) with that same lock makes the frozen install exit 1 without writing it, which is correct.
Expected
The same as bun install and npm ci: a lock entry that still satisfies its declared range is what gets installed. Only a dependency the lock does not cover, or one whose range no longer admits the pinned version, is resolved again. --frozen-lockfile then fails before installing anything, rather than after.
Why it matters
stacksjs/stacks commits pantry.lock, and its CI checks that an install leaves the lock alone. That check has gone red with no change in the repository, because curl.se moved from 8.22.0 to 8.23.0 upstream between two pushes (stacksjs/stacks#2905). The same thing will happen to every app that commits a lock, which is why Stacks can't yet put pantry install --frozen-lockfile in the CI it scaffolds.
Refs stacksjs/stacks#2905