Fix Pipenv requirements remedy categories (#1507)

[Mikola Lysenko (mikolalysenko)]

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

Fixes #1507

Summary

Socket Patch prints a remedy when a --site-packages Pipenv venv imports an
unpatched copy from its base interpreter (#1450). If the package was pinned in
several lock categories and at least one was named ([packages] + [docs],
[dev-packages] + [docs], …), the remedy printed
pipenv requirements --categories "packages docs". On Pipenv
2022.12.x–2023.2.4 that export is empty, so the follow-up
pip install -r installed nothing and exited 0. The venv kept the unpatched
copy and the warning came back on the next scan.

The export now names comma-joined lock keys
(--categories "default,docs"), which every Pipenv release that has
--categories reads. The pipenv sync remedies are unchanged and keep the
Pipfile names that sync takes.

Root cause

install_over_command (crates/socket-patch-core/src/vendor/pypi_pipenv.rs)
reused sync_args, which joins Pipfile names with spaces. That's correct for
pipenv sync, but pipenv requirements before 2023.2.18 splits
--categories on commas and looks each name up as a raw lock key. The fix
adds requirements_args, which keeps sync_args' plain/--dev forms and
renders named categories as comma-joined lock keys. Hosted and vendored
modes both go through this one function, so both are fixed. The npm, PyPI and
gem wrappers don't touch this code.

Test evidence

• New base_site_remedy_exports_comma_joined_lock_keys covers
  default+docs, develop+docs, default+develop+docs+tests and docs-only for
  both base-interpreter remedies. It also asserts that sync still takes
  Pipfile names. The existing Pipenv stale-install remedy can't replace a base-interpreter copy in a --site-packages venv: pip uninstall refuses it and pipenv sync keeps it, so following the warning leaves the package unpatched #1450 test's expectation was updated.

  • Red before the fix: both tests failed (cargo test -p socket-patch-core --lib base_site: 2 failed).
  • Green after: cargo test -p socket-patch-core --lib pypi_pipenv: 33 passed.

• Real Pipenv run against the issue's lock (default: idna, six; develop: six; docs: six):

  pipenv requirements --categories …	2022.12.19	2023.2.4	2026.9.1
  "packages docs" (old)	empty	–	–
  "dev-packages docs" (old)	empty	–	–
  "default,docs" (new)	idna six	–	idna six
  "develop,docs" (new)	six	–	six
  "default,develop,docs" (new)	idna six	idna six	idna six
  "docs" (new, single)	six	–	six

• cargo fmt --all -- --check: clean. cargo clippy --workspace --all-features -- -D warnings: clean.

• cargo test -p socket-patch-cli --all-features --lib: 919 passed.

• cargo test -p socket-patch-core --all-features: 6460 passed, 4 failed.
  The 4 failures are permission tests (copy_tree symlinked root,
  vlt_heal unremovable lock, pypi_poetry/pypi_requirements write
  failure). They can't fail as intended under root in this container, and
  they fail the same way with this PR's change reverted. CI runs as non-root.

• The full cargo test --workspace hit this container's disk allowance
  while linking integration-test binaries (no test failed), so CI's full run
  is the check for those suites. No CLI integration test asserts this remedy
  string.

Per-issue checklist

• Pipenv base-interpreter remedy (#1450) prints pipenv requirements --categories "packages docs", which Pipenv 2022.12.x–2023.2.4 export as empty, so following it installs nothing (exit 0) #1507: base_site_remedy_exports_comma_joined_lock_keys (red → green), plus the updated base_site_stale_install_remedy_installs_over_the_base_copy

/code-review high findings not fixed

• Category names containing commas, spaces or shell metacharacters aren't
  escaped. This predates the PR: sync_args has always inserted names
  as-is. Pipenv's own --categories parsing can't express such names
  either.
• The Pipenv backtest (scripts/backtest-pipenv.py) never runs the
  base-interpreter remedy, so it doesn't run the multi-category export. Adding
  that scenario is a separate change. I checked this PR by hand against real
  Pipenv releases (table above).
• The version note keys on the rendered --categories prefix. A
  develop-only pin exports --dev, which also covers default. Both
  predate the PR and this fix doesn't change them.
• The overlap between the updated Pipenv stale-install remedy can't replace a base-interpreter copy in a --site-packages venv: pip uninstall refuses it and pipenv sync keeps it, so following the warning leaves the package unpatched #1450 assertion and the new table is
  intentional: it keeps the original test's coverage of the full remedy text.

🤖 Generated with Claude Code

https://claude.ai/code/session_01CdJ5dk71VDEiEYvkU3ULap

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 9d5027f. Configure here.}