Sibling of #69's install-side fix, found while diagnosing cellbound-3d#151: Dev::Deps::BundlerRepository#run_bundle_lock invokes bare bundle lock, so dev update-deps resolves the gem graph under whatever Ruby the invoking shell carries — not the project's provisioned toolchain. On a host whose ambient Ruby mismatches the manifest pin, the lock either fails or resolves against the wrong interpreter.
Two parts:
- The
update-deps builtin never calls ShadowenvRuby.ensure! before resolving (unlike install_locked_deps), so there may be no provisioned Ruby to wrap with yet.
run_bundle_lock should then run through shadowenv exec in the project root, same doctrine as BundlerIntegration (see its comment: headless services have no shadowenv hook).
Ordering matters: provision first, then wrap — wrapping alone would still resolve bare on a fresh checkout with no .shadowenv.d.
Sibling of #69's install-side fix, found while diagnosing cellbound-3d#151:
Dev::Deps::BundlerRepository#run_bundle_lockinvokes barebundle lock, sodev update-depsresolves the gem graph under whatever Ruby the invoking shell carries — not the project's provisioned toolchain. On a host whose ambient Ruby mismatches the manifest pin, the lock either fails or resolves against the wrong interpreter.Two parts:
update-depsbuiltin never callsShadowenvRuby.ensure!before resolving (unlikeinstall_locked_deps), so there may be no provisioned Ruby to wrap with yet.run_bundle_lockshould then run throughshadowenv execin the project root, same doctrine asBundlerIntegration(see its comment: headless services have no shadowenv hook).Ordering matters: provision first, then wrap — wrapping alone would still resolve bare on a fresh checkout with no
.shadowenv.d.