GeezerVison

LLM Description written by Claude Code:claude-opus-5-5

Fixes #327
Fixes #329

Summary

scan --mode agent now finds the virtualenv Poetry actually installed into in four cases it used to miss. In each case the scan had fallen back to the wrong interpreter, skipped the patch as package_not_installed, and exited 0:

• a nameless package-mode = false project;
• a Poetry 2 project that sets both [project].name and [tool.poetry].name;
• an explicit virtualenvs.in-project = false next to a stray ./.venv;
• every default Windows project.

Changes, all in crates/socket-patch-core/src/crawlers/python_crawler.rs:

• Env name: poetry_project_names returns candidates in poetry-core's order: [project].name (2.x), then [tool.poetry].name, then non-package-mode. The first candidate that has a <name>-<hash>-py* dir on disk wins, so a Poetry 1.8 project (which ignores [project]) still finds its legacy-named env.
• In-project precedence: find_local_venv_site_packages asks Poetry's layered config first, following EnvManager.use_in_project_venv: an explicit in-project decides, and only when it is unset does an existing ./.venv count. When Poetry wouldn't use ./.venv, its out-of-tree env is probed before ./.venv and ./venv. Those stay as fallbacks when Poetry has no env.
• Windows hash: poetry_normalized_cwd goes through the new windows_normcase, which strips the \\?\ / \\?\UNC\ verbatim prefix as Python's realpath does, then lowercases. Pipenv's path normalization now shares the same strip_windows_verbatim_prefix helper.
• Docs: docs/testing/poetry-compatibility.md ("Mode notes") and a CHANGELOG Fixed entry.

The existing unit test poetry_project_names_prefer_tool_poetry_and_return_both_spellings asserted the old, wrong precedence. It is replaced by poetry_project_names_follow_poetry_core_precedence.

Root cause

find_poetry_virtualenv_site_packages rebuilds Poetry's virtualenv location without running Poetry, and it differed from Poetry in three places:

• It took the env name from [tool.poetry].name first and had no non-package-mode fallback. poetry-core 2.x's Factory uses project.get("name") or poetry_config.get("name", "non-package-mode"), and 1.9 uses local_config.get("name", "non-package-mode").
• It let ./.venv win unconditionally, even when Poetry's config said in-project = false.
• It hashed std::fs::canonicalize(cwd), which on Windows is \\?\C:\…. Poetry hashes normcase(realpath(cwd)), which has no such prefix.

Not in scope: the issues also point out that the scan exits 0 when the patch is skipped as package_not_installed. That's how agent mode handles any package that isn't installed, not something specific to Poetry. With discovery fixed, the patch applies in each of these cases.

Merge with v5 consolidation (#277), 2026-10-01

#277 landed on main and conflicted in python_crawler.rs and CHANGELOG.md. Merge commit df6cfba:

• find_local_venv_site_packages: kept this PR's Poetry-aware order. main had kept the old order, which probes .venv/venv first and Poetry only when they're empty, so taking main's side would bring Agent-mode scan misses Poetry's venv for nameless non-package-mode projects, [project].name overrides, and in-project = false with a stray .venv, and still exits 0 #327 case 3 back. The doc comment was updated to match.
• CHANGELOG.md: added the Poetry entry to main's consolidated ### Fixed list. The old NuGet <clear /> entry on this branch is dropped because main's consolidated list already covers it.
• No other code on main computes Poetry env names. vendor/pypi_poetry.rs::load_poetry_project is the lock/manifest reader and doesn't do venv discovery.

Re-validation after the merge:

• cargo test -p socket-patch-core --all-features --lib -- crawlers::python_crawler: 46 passed.
• cargo clippy --workspace --all-features -- -D warnings: clean.
• cargo fmt --all -- --check: this PR's code is clean. main itself has many pre-existing rustfmt diffs (e.g. apply.rs, scan/*.rs), and CI doesn't run fmt.
• cargo test --workspace --all-features --no-fail-fast: 9328 passed, 12 failed. All 12 are sandbox-only write-failure or permission tests that fail because the sandbox runs as root (*_write_failure_*, *unremovable*, relax_loop_must_not_traverse_symlinked_root, …). None of them are in the crawler.
• Poetry e2e locally (Poetry 2.1.1): vendored passed. Hosted failed only at rollback's GET https://pypi.org/pypi/six/1.16.0/json, because the binary's TLS stack doesn't trust the sandbox proxy CA (curl to the same URL returns 200). CI's e2e_vex_build poetry:: legs passed on df6cfba for 1.0.10, 1.1.15, 1.8.5, 2.0.1 and 2.4.3 (Linux) and 2.4.3 (macOS).
• CI on df6cfba: all 314 checks finished: success, apart from 4 that were skipped by design (e2e-docker, canary, downgrade, …). That includes test (ubuntu/macos/windows-latest), test-release and clippy. Bugbot's review of df6cfba found no issues. No conflict with main.

Test evidence (original change)

• Real Poetry 2.3.3 (Linux): I created real envs with poetry env use. find_local_venv_site_packages returned exactly the env poetry env info -p reports for the nameless, both-names and in-project = false projects.
• The npm wrapper only dispatches, so it needs no change. The PyPI and gem wrappers were removed in v5 prerelease: scan → vex → vendor workflow, hosted by default #277.

🤖 Generated with Claude Code

https://claude.ai/code/session_017mSDqYENPT34fbMjLSQzBg

Generated by Claude Code