GeezerVison

Assisted-by: Claude Code:claude-opus-5-5

A project that switched from vendor/bundle back to system gems
(`bundle config set path.system true`, or BUNDLE_PATH__SYSTEM=true)
usually still has the old gitignored vendor/bundle. The gem crawler
always counted that leftover store and, because it held gems, stopped
looking in the `gem env` homes. Agent apply then patched only the
unused copy, and vex attested not_affected while Bundler kept loading
the unpatched system gem.

The crawler now works out which Bundler settings tier decides the
install path (local config, then environment, then global config) and,
when that tier sets a truthy path.system, skips the default
vendor/bundle root so the system gem homes are crawled. path.system
values now follow Bundler's own boolean coercion, so "1" or "yes"
count as true too.

Fixes #915

Assisted-by: Claude Code:claude-opus-5-5

main has failed socket-patch-core's lib tests since Gradle support
(#646) and the digest helpers (#865) both landed. The guard test
production_digests_go_through_the_helpers flags three files #646 added
that still hash inline: crawlers/gradle_cache.rs, patch/jvm_jar.rs and
patch/sidecars/maven.rs. That breaks test, test-release and coverage on
every open PR.

Each inline sha1/sha256 call now goes through sha1_hex_of or
sha256_hex_of, which compute the same lowercase hex. Behaviour is
unchanged.

Assisted-by: Claude Code:claude-opus-5-5
(cherry picked from commit 659ac2c)

When the Bundler tier that wins sets path.system, Bundler also ignores
an env BUNDLE_PATH below it or beside it. If that value named the
leftover vendor/bundle, the crawler still probed it as the default
root and hid the system gem homes again, so apply and vex kept
targeting the unused copy. The env root is now skipped in that case
too.

Assisted-by: Claude Code:claude-opus-5-5

Assisted-by: Claude Code:claude-opus-5-5

With `default_install_uses_path` (Bundler 2.x) or `simulate_version 5`
(Bundler 4.x), and no path in any settings tier, `bundle install` puts
the project's gems in `<root>/.bundle/<engine>/<abi>/gems` and `bundle
exec` loads them from there. The gem crawler never probed that root,
so agent `apply` patched only the system copy, `vex` attested
not_affected over the unpatched loaded copy, and the hosted
stale-install guard missed a stale `.bundle` materialization.

Resolve the deciding Bundler path tier once (explicit path and
`path.system`) and probe `<root>/.bundle` whenever that tier names no
path and no truthy `path.system`, mirroring `Path#base_path`. Like the
other explicit roots it keeps the `gem env` fallback on for default
gems.

Fixes #967

Assisted-by: Claude Code:claude-opus-5-5

Assisted-by: Claude Code:claude-opus-5-5

cursor Bot left a comment •

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.

#916 merged into main as a squash, so the stacked ruby_crawler.rs and
crawler_ruby_e2e.rs conflicted against its own content. Take main's copy
of both files and replay only this PR's .bundle-root changes (#967) on
top, so the path.system logic stays exactly as reviewed on main.

Also pass std::env::var_os directly in the new env-guard test helper to
satisfy clippy's redundant_closure lint.

Co-Authored-By: Claude <[email protected]>

cursor Bot left a comment •

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.

cursor Bot left a comment