GeezerVison

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

Fixes #449
Fixes #451

Summary

scan -g / get -g / apply -g / rollback -g / vex -g now find:

• uv tool envs and uv-managed Pythons wherever uv puts them, and
• PDM's global installs.

Before this change they were silently skipped and the run still exited 0.

Root cause

get_global_python_site_packages (crates/socket-patch-core/src/crawlers/python_crawler.rs) hard-coded where Python tools keep their global environments. It didn't follow each tool's own path resolution:

• uv (Global scan (-g) misses uv tool environments on Windows (looks in %LOCALAPPDATA%\uv\tools, uv uses %APPDATA%\uv\tools) and on every OS when UV_TOOL_DIR, XDG_DATA_HOME or UV_PYTHON_INSTALL_DIR is set #449): tool envs were scanned at %LOCALAPPDATA%\uv\tools on Windows, but uv uses %APPDATA%\uv\tools. UV_TOOL_DIR, UV_PYTHON_INSTALL_DIR and XDG_DATA_HOME were never read.
• PDM (Global scan (-g) never crawls PDM's global project venv or PDM-managed interpreters, so pdm add -g packages are silently left out with exit 0 #451): there were no PDM entries at all.

Fix

New helpers sit next to the existing pipx_home_candidates. They return every root the tool may use, and global discovery scans the ones that exist:

• uv_dir_candidates(home, override_var, bucket) mirrors uv's StateStore::from_settings. The candidates are:

  • $UV_TOOL_DIR / $UV_PYTHON_INSTALL_DIR, made absolute against the cwd as uv does;
  • $XDG_DATA_HOME/uv/<bucket> (absolute only);
  • ~/.local/share/uv/<bucket> on Unix;
  • %APPDATA%\uv\<bucket> on Windows;
  • the legacy roots: macOS ~/Library/Application Support/uv, and Windows %LOCALAPPDATA%\uv, which earlier releases scanned.

  I checked these rules against real uv 0.8.17 (uv tool dir / uv python dir under each env var; a relative XDG_DATA_HOME is ignored). The Windows default is the one reported in Global scan (-g) misses uv tool environments on Windows (looks in %LOCALAPPDATA%\uv\tools, uv uses %APPDATA%\uv\tools) and on every OS when UV_TOOL_DIR, XDG_DATA_HOME or UV_PYTHON_INSTALL_DIR is set #449.

• pdm_global_site_packages(home) mirrors PDM 2.29's project/config.py and Project.__init__, plus platformdirs. It covers:

  • the global project (global_project.path, default <user_config_dir>/pdm/global-project) and its .venv;
  • an out-of-tree <venv.location>/global-project-<hash>-<py> venv;
  • the interpreter recorded in its .pdm-python (the PDM 2.12 pdm use -g case);
  • every interpreter under python.install_root (default <user_data_dir>/pdm/python).

  The settings are read from $PDM_CONFIG_FILE or <user_config_dir>/pdm/config.toml, with ~ expanded. The user dirs follow platformdirs: $XDG_CONFIG_HOME / $XDG_DATA_HOME, ~/.config / ~/.local/share on Linux, ~/Library/Application Support/pdm on macOS, and %LOCALAPPDATA%\pdm\pdm on Windows.

• The uv tool, uv Python and pipx scans now share find_child_env_site_packages, so lib64 multilib venvs are covered for uv too.

No wrapper changes are needed: npm/, pypi/ and gem/ only dispatch the binary.

Test evidence

Tests are in crates/socket-patch-core/tests/crawler_python_e2e.rs. They pin HOME and every relocating env var, so ambient host values can't decide the result.

cargo test -p socket-patch-core --test crawler_python_e2e, Linux:

• With this PR: 58 passed, 0 failed.
• With python_crawler.rs reverted to main: 11 failed, which is every new Linux-applicable test.

Two more tests are Windows-only (cfg(windows)) and run on the Windows CI leg: ..._uv_tools_under_appdata and ..._uv_python_under_appdata.

Per-issue checklist:

• Global scan (-g) misses uv tool environments on Windows (looks in %LOCALAPPDATA%\uv\tools, uv uses %APPDATA%\uv\tools) and on every OS when UV_TOOL_DIR, XDG_DATA_HOME or UV_PYTHON_INSTALL_DIR is set #449 UV_TOOL_DIR: get_global_python_site_packages_discovers_uv_tools_under_uv_tool_dir (red → green)
• Global scan (-g) misses uv tool environments on Windows (looks in %LOCALAPPDATA%\uv\tools, uv uses %APPDATA%\uv\tools) and on every OS when UV_TOOL_DIR, XDG_DATA_HOME or UV_PYTHON_INSTALL_DIR is set #449 XDG_DATA_HOME tools: ..._discovers_uv_tools_under_xdg_data_home (red → green)
• Global scan (-g) misses uv tool environments on Windows (looks in %LOCALAPPDATA%\uv\tools, uv uses %APPDATA%\uv\tools) and on every OS when UV_TOOL_DIR, XDG_DATA_HOME or UV_PYTHON_INSTALL_DIR is set #449 UV_PYTHON_INSTALL_DIR: ..._discovers_uv_python_under_install_dir (red → green)
• Global scan (-g) misses uv tool environments on Windows (looks in %LOCALAPPDATA%\uv\tools, uv uses %APPDATA%\uv\tools) and on every OS when UV_TOOL_DIR, XDG_DATA_HOME or UV_PYTHON_INSTALL_DIR is set #449 XDG_DATA_HOME python: ..._discovers_uv_python_under_xdg_data_home (red → green)
• Global scan (-g) misses uv tool environments on Windows (looks in %LOCALAPPDATA%\uv\tools, uv uses %APPDATA%\uv\tools) and on every OS when UV_TOOL_DIR, XDG_DATA_HOME or UV_PYTHON_INSTALL_DIR is set #449 Windows %APPDATA%\uv\tools / \python: ..._uv_tools_under_appdata, ..._uv_python_under_appdata (Windows CI)
• Global scan (-g) never crawls PDM's global project venv or PDM-managed interpreters, so pdm add -g packages are silently left out with exit 0 #451 global project .venv: ..._discovers_pdm_global_project_venv (red → green)
• Global scan (-g) never crawls PDM's global project venv or PDM-managed interpreters, so pdm add -g packages are silently left out with exit 0 #451 XDG_CONFIG_HOME: ..._discovers_pdm_global_project_under_xdg_config_home (red → green)
• Global scan (-g) never crawls PDM's global project venv or PDM-managed interpreters, so pdm add -g packages are silently left out with exit 0 #451 PDM-managed interpreters: ..._discovers_pdm_managed_interpreters (red → green)
• Global scan (-g) never crawls PDM's global project venv or PDM-managed interpreters, so pdm add -g packages are silently left out with exit 0 #451 global_project.path / python.install_root overrides via PDM_CONFIG_FILE: ..._follows_pdm_config_overrides (red → green)
• Global scan (-g) never crawls PDM's global project venv or PDM-managed interpreters, so pdm add -g packages are silently left out with exit 0 #451 default config.toml: ..._reads_pdm_default_config_file (red → green)
• Global scan (-g) never crawls PDM's global project venv or PDM-managed interpreters, so pdm add -g packages are silently left out with exit 0 #451 .pdm-python interpreter (PDM 2.12 no-venv case): ..._follows_pdm_global_project_interpreter (red → green)
• Global scan (-g) never crawls PDM's global project venv or PDM-managed interpreters, so pdm add -g packages are silently left out with exit 0 #451 venv.location out-of-tree global venv, and other projects' venvs excluded: ..._discovers_pdm_global_project_out_of_tree_venv (red → green)

Local checks:

• cargo clippy --workspace --all-features -- -D warnings: clean.
• cargo test --workspace --all-features --no-fail-fast: 9,479 passed, 12 failed. Every failure is a write-failure test that makes a dir read-only with chmod, which root (this sandbox) ignores: covgap_commands_vendor ×3, in_process_redirect ×3, repair ×2, core lib ×4. The same core lib failures reproduce on unmodified main here. None of them touch the Python crawler. CI runs as a non-root user.
• cargo fmt --all -- --check: main itself isn't rustfmt-clean with the pinned 1.93.1 toolchain, and CI doesn't run it. I formatted only the hunks this PR touches.

Review rounds

• Bugbot (1a82a49) noted that ~ in PDM settings was expanded from HOME on Windows, while Python's expanduser uses USERPROFILE. Fixed in e5ab4b5, and the override test now covers it on Windows. Bugbot's review of e5ab4b5 found no issues.

Follow-ups

None. macOS's legacy ~/Library/Application Support/uv root is still scanned. I didn't add %APPDATA%\uv\data (the directories-crate legacy root on Windows) because I couldn't confirm uv ever used it.

🤖 Generated with Claude Code

https://claude.ai/code/session_011Y5WmyS6GcEUtn5VVPwYXu

Generated by Claude Code