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

[mikolalysenko]

[agent] Found by the scheduled PDM bug-hunt routine (ledger #312).

Summary

socket-patch scan -g (and SOCKET_GLOBAL=1) misses packages in the two places PDM puts global installs once a global interpreter is selected:

1. The PDM global project's virtualenv. pdm use -g <python> with a non-venv interpreter creates <user_config_dir>/pdm/global-project/.venv on PDM 2.29 (python.use_venv, the default). After that, every pdm add -g installs there (~/.config/pdm/global-project/.venv/lib/python3.X/site-packages on Linux).
2. PDM-managed interpreters. pdm python install 3.12 puts CPython under python.install_root = <user_data_dir>/pdm/python/cpython@3.12.N/ (~/.local/share/pdm/python/... on Linux). On PDM 2.12, pdm use -g with such an interpreter makes pdm add -g install straight into its lib/python3.12/site-packages.

get_global_python_site_packages() lists the system and user site dirs, Homebrew, the python.org framework, pyenv, conda, uv tools and uv-managed interpreters. It has no PDM entry, so neither location is crawled. The scan exits 0, and the missed packages are absent from the batch query.

Impact

scan -g reports nothing for these packages, so a patch for them is never surfaced. Agent-mode scan -g --mode agent, get -g, apply -g, rollback -g and vex -g resolve their site-packages through the same get_site_packages_paths() branch (python_crawler.rs:1399). From reading the code, they'd also skip these packages. I only proved the scan-discovery miss with a real install, not apply or vex. The workaround is --global-prefix <site-packages>, which does find them (see below).

The default first pdm add -g with no pdm use -g installs into the system interpreter (/usr/local/lib/python3.11/dist-packages here), and that is found. The bug needs pdm use -g or pdm python install, which is PDM's documented way to pick the global interpreter.

Repro (Linux, real PDM 2.29.2, logging mock for POST /patch/batch via SOCKET_PROXY_URL)

export HOME=$(mktemp -d) PDM_CHECK_UPDATE=false
uv venv -q pdmenv && VIRTUAL_ENV=$PWD/pdmenv uv pip install -q pdm==2.29.2; PDM=$PWD/pdmenv/bin/pdm
cd "$HOME"
$PDM python install 3.12
PY=$(ls -d $HOME/.local/share/pdm/python/cpython@3.12*/bin/python3)
$PY -m pip install iniconfig==2.0.0          # (a) package in the PDM-managed interpreter
$PDM use -g -f "$PY"                          # creates ~/.config/pdm/global-project/.venv
$PDM add -g idna==3.6                         # (b) package in the global project venv
cd /tmp
socket-patch scan -g --ecosystems pypi --json # inspect the PURLs POSTed to /patch/batch
socket-patch scan --ecosystems pypi --json --global-prefix ~/.config/pdm/global-project/.venv/lib/python3.12/site-packages
socket-patch scan --ecosystems pypi --json --global-prefix ~/.local/share/pdm/python/cpython@3.12.14/lib/python3.12/site-packages

Output, 2 of 2 fresh runs (the mock records every PURL the CLI queries):

~/.config/pdm/global-project/.venv/lib/python3.12/site-packages/idna-3.6.dist-info
~/.local/share/pdm/python/cpython@3.12.14/lib/python3.12/site-packages/iniconfig-2.0.0.dist-info
--- scan -g
exit=0 scanned=48
matching: []                                   <- neither package queried
--- scan --global-prefix <global-project venv>
exit=0 scanned=5
matching: ['pkg:pypi/idna@3.6']
--- scan --global-prefix <pdm python>
exit=0 scanned=2
matching: ['pkg:pypi/iniconfig@2.0.0']

With PDM 2.12.4, pdm use -g -f <pdm-managed python3.12> followed by pdm add -g iniconfig==2.0.0 installs into cpython@3.12.14/lib/python3.12/site-packages with no venv. scan -g again doesn't query iniconfig. Running scan -g from inside the global project directory doesn't help either.

Expected vs actual

• Expected: CLI_CONTRACT.md documents --global / -g / SOCKET_GLOBAL as "Operate on globally-installed packages". The crawler already treats uv's equivalents as global, both uv tools and uv-managed interpreters (python_crawler.rs:1250, :1296). PDM's global project venv and python.install_root interpreters are the PDM counterparts. A pdm add -g package should be discovered.
• Actual: both locations are skipped, the scan exits 0, and the user gets no hint that global PDM installs exist.

OS × PDM

PDM	global install location	Linux	macOS	Windows
2.29.2	default (system interpreter, no pdm use -g)	found	—	—
2.29.2	pdm use -g → global-project/.venv	missed	not probed	not probed
2.29.2	PDM-managed cpython@3.12 site-packages	missed	not probed	not probed
2.12.4	default (system interpreter)	found	—	—
2.12.4	pdm use -g <pdm-managed python> (no venv)	missed	not probed	not probed

macOS and Windows weren't probed this run, because probe branches can't currently be deleted from the routine's sandbox. From PDM's project/config.py the paths are platformdirs.user_config_path("pdm")/global-project and platformdirs.user_data_dir("pdm")/python. That is ~/Library/Application Support/pdm/... on macOS and %LOCALAPPDATA%\pdm\pdm\... on Windows, and neither is in the global list on any OS. global_project.path, python.install_root and venv.location (when venv.in_project=false) can also be overridden in PDM's config.

Suspect code

• crates/socket-patch-core/src/crawlers/python_crawler.rs:1073 (get_global_python_site_packages): no PDM global project / python.install_root entries.
• crates/socket-patch-core/src/crawlers/python_crawler.rs:1399: the -g branch returns only that list.

Related, for other Python tools: #415 (pipx venvs) and #449 (uv tool dirs on Windows and under env overrides).

Tested on main 2463257 (latest tag v4.0.0), release build. No first-bad bisect: the global list has never contained PDM paths.

[mikolalysenko]

[agent] Shares root cause with #449: get_global_python_site_packages (python_crawler.rs:1073) hard-codes tool env roots instead of following each tool's own path resolution (env overrides, platformdirs). Will be fixed together. #415 (pipx) is the same function and is already in flight in #418.

Triage: priority:p1 (PDM). Confirmed on main 2463257: the global list has no entry for the PDM global project venv or for python.install_root. I found no duplicate or existing fix PR.

---

Generated by Claude Code

[mikolalysenko]

[agent] Claiming this issue (with #449; shared root cause: get_global_python_site_packages hard-codes tool env roots instead of following each tool's own path resolution). Branch: agent/fix-python-global-tool-roots. Claim-ID: 2026-10-02T02:20:32Z-389d97

---

Generated by Claude Code

[mikolalysenko]

[agent] Draft fix PR: #522

---

Generated by Claude Code

[mikolalysenko]

[agent] I checked PR #522 (head e5ab4b5) against real PDM global installs on Linux. Each case ran in an isolated HOME / XDG dirs, with pdm add -g urllib3==1.26.17, then scan -g --mode agent --yes → import check → rollback -g:

PDM	global env	main 61cfb9b	#522 e5ab4b5
2.29.2	global-project/.venv (pdm use -g)	applied 0, upstream	applied 1, patched; rollback byte-exact
2.29.2	venv.in_project=false → <data>/pdm/venvs/global-project-<hash>-3.11	applied 0	applied 1, patched; rollback restores
2.29.2	PDM-managed cpython@3.12.14 (pdm python install, python.use_venv=false)	applied 0	applied 1, patched; rollback restores
2.12.4	global-project/.venv	applied 0	applied 1, patched; rollback restores
2.12.4	out-of-tree global-project-<hash>-3.11 venv	applied 0	applied 1, patched; rollback restores

One caveat. #522 doesn't fix this case, and it isn't a regression: if the same release is also installed in a global location that's crawled earlier (here the system /usr/local/lib/python3.11/dist-packages and a pipx venv, both urllib3==1.26.18), PythonCrawler::crawl_all keeps only the first site-packages per PURL (python_crawler.rs:1742, seen.insert(purl)). So scan -g patches only that copy (applied: 1) and the PDM global copy stays upstream. That's the root cause #501 already tracks; I'm noting it here so the PDM global case gets re-checked once #501 is fixed.

---

Generated by Claude Code