Repository navigation
Global scan (-g) ignores PDM's site-wide config, so a global project relocated in /etc/xdg/pdm/config.toml is never crawled and get -g reports "applied" while the copy PDM runs stays unpatched #566
Description
[agent] Found by the scheduled PDM bug-hunt routine (ledger #312).
Summary
#522 (fixing #451) taught -g discovery to read PDM's global_project.path, venv.location and python.install_root settings. It reads them only from $PDM_CONFIG_FILE and the user config (<user config dir>/pdm/config.toml). PDM also reads a site config, platformdirs.site_config_path("pdm") / "config.toml", and uses it as the defaults layer under the user config (Config.get_defaults() in pdm/project/config.py, present since PDM 2.0). On Linux that file is /etc/xdg/pdm/config.toml (first entry of $XDG_CONFIG_DIRS). On macOS it's /Library/Application Support/pdm/config.toml, and on Windows C:\ProgramData\pdm\pdm\config.toml.
If an image or a managed machine sets [global_project] path in the site config, pdm add -g installs into <that path>/.venv, and pdm run -g python uses that venv. socket-patch never looks there.
Impact
scan -gexits 0 withpackagesWithPatches: 0while a patchablepdm add -gpackage is installed.- When the same release is also somewhere
-gdoes crawl (the system interpreter, for example),get -g/apply -gprint1 of 1 targeted patch appliedand patch that copy. The copy PDM's global project actually imports stays unpatched, and nothing warns about it.vex -ghas the same blind spot. - With the identical setting in the user config, everything works (control below), so the defect is the missing config layer, not the relocation.
Repro (Linux, real PDM 2.29.2 or 2.12.4, local mock patch API serving a patched urllib3 1.26.18)
export HOME=$(mktemp -d)
mkdir -p /etc/xdg/pdm
printf '[global_project]\npath = "/opt/bh/global"\n' > /etc/xdg/pdm/config.toml
pdm config global_project.path # -> /opt/bh/global (PDM honours the site config)
mkdir -p /opt/bh/global && uv venv -p 3.11 /opt/bh/global/.venv
pdm use -g -f /opt/bh/global/.venv/bin/python
pdm add -g urllib3==1.26.18 # installs into /opt/bh/global/.venv
pdm run -g python -c 'import sys;print(sys.prefix)' # -> /opt/bh/global/.venv
socket-patch scan -g --json # status success, packagesWithPatches 0
socket-patch get -g pkg:pypi/urllib3@1.26.18 --yes
tail -1 /opt/bh/global/.venv/lib/python3.11/site-packages/urllib3/_version.py # still upstream
# control: move the same two lines to $HOME/.config/pdm/config.toml and remove /etc/xdg/pdm.
# scan -g finds it, get -g patches the global-project copy, rollback -g restores it.Expected vs actual
- Expected: per Fix global Python scan missing uv and PDM installs (#449, #451) #522's commit message, global discovery "follows each tool's own path rules: … PDM's platformdirs config/data dirs plus the global_project.path, python.install_root and venv.location settings".
--globalis documented as "Operate on globally-installed packages" (CLI_CONTRACT.md, global flags table). PDM resolves those settings through the site config too, so the global project PDM uses should be crawled. - Actual: the site config is never read. The relocated global project is invisible, and
get -gcan report success after patching a different copy.
Matrix (main d63ae5f)
| OS | PDM | setting in site config | result |
|---|---|---|---|
| Linux | 2.29.2 | global_project.path |
fail (scan -g: 0; get -g patches the system copy, global-project copy unpatched) |
| Linux | 2.12.4 | global_project.path |
fail (scan -g: 0) |
| Linux | 2.29.2 | same setting in the user config (control) | pass (found, patched, rollback restores) |
| macOS / Windows | — | — | untested (same code path, so likely to fail) |
Reproduced 3/3 on Linux. PDM 2.0.3's config.py already has the site layer, so every 2.x release is in scope. venv.location and python.install_root set in the site config are missed for the same reason (same code path). I didn't isolate those in this run, because a stray system-interpreter copy masked the scan count.
Suspect code
crates/socket-patch-core/src/crawlers/python_crawler.rs:1772-1777 (pdm_global_site_packages): config_files holds only $PDM_CONFIG_FILE plus pdm_dir_candidates(.., "XDG_CONFIG_HOME", ..). It's missing the site config dirs: $XDG_CONFIG_DIRS entries (default /etc/xdg) on Linux, /Library/Application Support on macOS, and %PROGRAMDATA%\pdm\pdm on Windows. They need to be read as a lower-precedence layer than the user file.
No probe runs (Linux only).
Activity
mikolalysenko commentedon Oct 2, 2026
[agent] Triage: priority:p1 (PDM). Confirmed on main: the
-gPDM settings reader incrawlers/python_crawler.rs(~L1750-1810) consults only$PDM_CONFIG_FILEand the user config; nothing reads the platformdirs site config (/etc/xdg/pdm/config.tomletc.). Distinct root cause from open #540 (project env discovery); no open PR covers it.Generated by Claude Code
mikolalysenko commentedon Oct 2, 2026
[agent] Shares root cause with #609: PDM settings are read from one file at a time, not through PDM's layered config (env > project >
$PDM_CONFIG_FILE/user > site, withensure_boolean-style coercion). Will be fixed together.Generated by Claude Code
mikolalysenko commentedon Oct 2, 2026
[agent] Claiming this issue (with #609; shared root cause: PDM settings aren't resolved through PDM's layered config). Branch: agent/fix-pdm-layered-config. Claim-ID: 2026-10-02T21:20:53Z-8748ca
Generated by Claude Code
mikolalysenko commentedon Oct 2, 2026
[agent] Draft PR: #611
Generated by Claude Code
Read PDM settings through PDM's config layers
Fix PDM settings ignoring PDM's config layers (#609, #566) (#611)
mikolalysenko commentedon Oct 5, 2026
[agent] Janitor: closing as completed. PR #611 (merge
2465131e, "Fixes #609 and #566") merged into main. GitHub auto-closed only #609. On origin/main6811b4e7,pdm_global_site_packages_withincrawlers/python_crawler.rs(~L2378–2400) now readsglobal_project.path,venv.locationandpython.install_rootfrom the site config layer too, throughpdm_site_config_dirs(~L2322; first absolute$XDG_CONFIG_DIRSentry, with platform defaults). Reopen if-gstill misses a site-relocated global project.Generated by Claude Code