Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Vendored PyPI revert drift warnings print the ledger key in Rust debug form: `Pipfile.lock entry for Some("default:six") changed since vendoring`

Open Beginner friendly
  • Is something wrong?
#1,608 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
78/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
rust
Domain
tooling

Research direction

The bad output comes from the {:?} formatting of the Option<String> key in WiringRecord::key (crates/socket-patch-core/src/vendor/state.rs), used in pypi_pipenv.rs (vendor_lock_entry_drifted) and pypi_requirements.rs (vendor_revert_line_drifted), with the same pattern in pypi_uv.rs and common.rs. Start by reading those four call sites and the existing vendor_revert_residual_reference warning, which already prints keys plainly. Done means the drift warnings print the bare key or a placeholder for None, and the revert/rollback tests still pass.

Written by the indexing model from the issue text.

Description

agent:triaged bug bughunt pm:pipenv priority:p1

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

Summary

When a vendored Pipenv project's recorded wiring has drifted, vendor --revert, remove and rollback warn with the ledger key formatted through {:?} on an Option<String>. The warning, in both human output and --json warning text, shows a Rust Some("…") wrapper instead of the key:

Warning: Pipfile.lock entry for Some("default:six") changed since vendoring; left untouched
Warning: requirements.txt: the vendor line for Some("requirements.txt:1") changed since vendoring; left untouched

Impact

This is cosmetic only. The keep/restore behaviour is correct, nothing is unpatched silently, and VEX isn't affected. But the debug form leaks into user-facing text and into the --json warning messages that CI consumers read. When the key is missing (None, e.g. an older or hand-written ledger), the warning would print entry for None.

Repro (Linux, main 657fce2 / 5.0.1, real Pipenv 2026.9.1, local mock of the patch API serving a patched six-1.16.0 wheel)

cat > Pipfile <<'EOF'
[[source]]
url = "https://pypi.org/simple"
verify_ssl = true
name = "pypi"

[packages]
six = "==1.16.0"

[requires]
python_version = "3.11"
EOF
pipenv lock
socket-patch scan --mode vendored --yes          # Pipfile.lock six → ./.socket/vendor/pypi/<uuid>/six-…whl
# drift the vendored entry (any field the ledger recorded, e.g. its markers)
sed -i "s/python_version >= '2.7' and/python_version >= '2.8' and/" Pipfile.lock
socket-patch vendor --revert --yes               # Warning: Pipfile.lock entry for Some("default:six") changed since vendoring; left untouched
socket-patch rollback --yes --json | grep -o 'entry for Some[^;]*'   # entry for Some(\"default:six\") changed since vendoring

The requirements.txt variant: vendor with a sibling requirements.txt holding six==1.16.0, then hand-restore that line (or interrupt a remove with SIGKILL after it restored requirements.txt but before it dropped the ledger) and re-run vendor --revert. It prints the vendor line for Some("requirements.txt:1") changed since vendoring.

Expected vs actual

  • Expected: the warning names the entry as the ledger records it (Pipfile.lock entry for default:six …, the vendor line for requirements.txt:1 …). Other warnings in the same code path print keys plainly, e.g. the vendor_revert_residual_reference text.
  • Actual: Some("default:six") / Some("requirements.txt:1").

OS × version

OS Pipenv vendor --revert rollback remove
Linux 2026.9.1 reproduces (×2) reproduces (×2) reproduces (requirements.txt variant)
macOS / Windows not probed: the string formatting is platform-independent

No bisect, because the format strings predate the current history.

Suspect code

WiringRecord::key is Option<String> (crates/socket-patch-core/src/vendor/state.rs:143), and these format it with {:?}:

  • crates/socket-patch-core/src/vendor/pypi_pipenv.rs:569 (vendor_lock_entry_drifted)
  • crates/socket-patch-core/src/vendor/pypi_requirements.rs:601 (vendor_revert_line_drifted)
  • the same pattern at crates/socket-patch-core/src/vendor/pypi_uv.rs:991 and crates/socket-patch-core/src/vendor/common.rs:826 (not exercised here; they likely show the same leak for uv and the other common.rs users)

A fix along the lines of rec.key.as_deref().unwrap_or("<unknown>") with {} would cover all four.

Dominant language
Rust
Stars
8
Forks
1
Avg merge
16h 19m
Merged PRs (30d)
586

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from SocketDev/socket-patch

All issues in SocketDev/socket-patch

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.