Fix pyproject product detection tables (#1527, #642)

[Mikola Lysenko (mikolalysenko)]

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

Fixes #1527
Fixes #642

Summary

vex and scan --vex now detect the product for two documented pyproject layouts that failed with product_undetected (exit 2 for vex, exit 1 for scan --vex after it had already rewritten the lock):

• VEX product detection fails on Poetry 2 projects that declare dynamic = ["version"] with the version in [tool.poetry], so scan --vex exits 1 after rewriting poetry.lock #1527, Poetry 2: [project].name with dynamic = ["version"] and the version in [tool.poetry].version now gives pkg:pypi/demo@0.3.0.
• VEX product detection ignores PDM 0.x's [tool.pdm] name/version, so vex and scan --vex fail with product_undetected on PDM 0.12 projects (after scan has already rewritten pdm.lock) #642, PDM 0.x: the legacy [tool.pdm] name/version table now gives pkg:pypi/x@0.0.0.

Root cause

vex/product.rs::parse_pyproject took name and version from one table only ([project], else [tool.poetry]), each read by a line scanner that needed both keys in that table. It never combined [project].name with Poetry 2's dynamic version, and it never read [tool.pdm].

Fix

• pyproject.toml is now read with toml_edit, the crate's existing TOML parser, instead of the line scanner. Multi-line dynamic arrays, dotted keys and inline tables now parse the way tomllib parses them. A BOM'd file still yields no product, as before, because tomllib refuses it. The check goes through formats::text::BOM.
• Order: [project] name+version. Then, when Poetry builds the project, poetry-core's own merge (Factory.create_poetry): the name is [project].name or else [tool.poetry].name, and the version is [project].version or else [tool.poetry].version. Last comes legacy [tool.pdm].
• If [project].name and [tool.poetry].name differ, no product is named, because Poetry 2 builds the first and Poetry 1.x the second.
• "Poetry builds it" means no build-backend is declared, or it is under poetry. or is poetry_dynamic_versioning.backend, and the poetry-dynamic-versioning plugin is not enabled. Under the enabled plugin the version is a placeholder like 0.0.0. Under hatch-vcs or setuptools-scm the table is a leftover. In both cases detection names no product rather than a version that is never built.
• The old scanner's unit tests now run against the new reader through test-only shims.

Not in this PR: scan --vex resolving the product only after it writes is tracked in #1064.

Per-issue checklist

• VEX product detection fails on Poetry 2 projects that declare dynamic = ["version"] with the version in [tool.poetry], so scan --vex exits 1 after rewriting poetry.lock #1527: detect_pyproject_poetry2_dynamic_version (the issue's exact pyproject), pyproject_poetry2_multiline_dynamic_version, pyproject_static_version_wins_over_tool_poetry_version, pyproject_tool_poetry_version_without_dynamic, pyproject_conflicting_poetry_names_is_none, pyproject_dynamic_versioning_backend_disabled_keeps_static_version, pyproject_dynamic_version_without_tool_poetry_is_none, pyproject_poetry_dynamic_versioning_placeholder_is_none, pyproject_tool_poetry_version_ignored_under_other_backend
• VEX product detection ignores PDM 0.x's [tool.pdm] name/version, so vex and scan --vex fail with product_undetected on PDM 0.12 projects (after scan has already rewritten pdm.lock) #642: detect_pyproject_pdm_legacy_table (the issue's exact PDM 0.12 pyproject), pyproject_project_wins_over_tool_pdm

Test evidence

• Red on main: cargo test -p socket-patch-core --all-features --lib vex::product → detect_pyproject_poetry2_dynamic_version, pyproject_poetry2_multiline_dynamic_version and detect_pyproject_pdm_legacy_table FAILED (132 passed, 3 failed).
• Green on the branch: cargo test -p socket-patch-core --all-features --lib -- vex:: formats::text → 700 passed, 0 failed.
• cargo fmt --all -- --check and cargo clippy --workspace --all-features -- -D warnings are clean.
• cargo test --workspace --all-features --no-fail-fast: everything passes except tests that make a file or directory read-only or unremovable and expect a write to fail (covgap_commands_vendor, in_process_redirect, repair, plus 4 core tests such as wire_failure_rolls_back_already_written_files), and one in e2e_bun_lockb. The sandbox runs as root, where chmod doesn't block writes. The 4 core tests fail the same way without the last two commits, and none of these tests touch vex/product.rs. CI runs them as a non-root user.
• No wrapper (npm/pypi/gem) changes: product detection is in the Rust core only.

/code-review high findings not fixed

• toml_edit parses TOML 1.1 while tomllib parses 1.0. A pyproject that uses only 1.1 syntax, such as a multi-line inline table or a \e escape, would yield a product that pip can't build. That needs a hand-written 1.1-to-1.0 validator, which is far more code than the risk justifies.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Ekek5ktEG5b5ujMggdbzyu

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[cursor]

Stale Bugbot comment from a previous run.

[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 66c36d2. Configure here.}