pip-install-editable-dev-extra-pep735-not-installed
Solution written to ~/solution.md.
Diagnosis (reproduced exactly): The repo declares dev tooling via PEP 735 [dependency-groups] dev = [...]. .[dev] is an extras reference, and extras come only from [project.optional-dependencies]. pip installs the project with no pytest but exits 0, printing only:
WARNING: mypkg 1.1.0 does not provide the extra 'dev'
So the || pip install -e . fallback (rc-only) never fires, and the venv ends up with runtime deps only. The bare pytest then yields rc=127, which contaminates downstream cells — including a false OK in the chaos-disconnect cell where else -> OK swallows a missing-tool rc.
Exact fix (3 layers):
1. Install explicitly: pip install -e . && pip install pytest (or uv ... --group dev), then assert the runner exists.
2. Grep the install log for does not provide the extra and abort — rc=0 must not be trusted.
3. Classify 127 / command not found as INFRA before the cell's semantic rc branches; use python -m pytest.
Verification performed in throwaway copies:
- Broken: INSTALL_RC=0 + warning, pytest rc=127, python -m pytest rc=1 (no module).
- Fixed script on a PEP 735 repo → 1 passed, exit 0.
- Fixed script on a classic extras repo → 1 passed, exit 0 (no regression).
- Included bunker-qa.sh-style guard using stdlib tomllib to detect group vs extra and fail loud.
Target repo was not modified.
# Evidence - Problem class: pip-install-editable-dev-extra-pep735-not-installed - Model: openrouter/deepseek/deepseek-v4.1-flash - Solved: 2026-09-16T01:14:53.256Z - Verification: solution produced by pi in sandbox; see signatures.json
{"description": "SYMPTOM. A QA/CI harness runs `pip install -e .[dev]` to prepare a Python repo, then runs the test suite as `pytest -x -q`. The suite never executes: rc=127 `pytest: command not found`, and every downstream cell that depends on the suite inherits the rc=127.\n\nROOT CAUSE. The repo declares its dev dependency the PEP 735 way:\n [dependency-groups]\n dev = [\"pytest>=8\"]\n`.[dev]` is an EXTRAS reference, and extras come only from [project.optional-dependencies]. PEP 735 dependency-groups are NOT extras, so pip installs the project without pytest and exits 0 with a warning:\n WARNING: <pkg> 1.1.0 does not provide the extra 'dev'\nBecause the exit code is 0, any `pip install -e .[dev] 2>/dev/null || pip install -e .` fallback NEVER fires - the fallback line only protects against a non-zero rc, and this failure mode is rc=0. The venv therefore ends up with the runtime deps only (observed: 'Successfully installed PyYAML-6.0.3 mypkg-1.1.0' - no pytest).\n\nWHY IT LIES. Metrics driven off the test command then mislabel a MISSING TOOL as a product/test outcome:\n - a 'ci-pass' cell reports FAIL with the native leg at rc=127 (the suite never ran), which reads as repo brittleness in CI dashboards;\n - a chaos/disconnect cell whose branches are `rc==0 -> INFO`, `rc==124 -> FAIL (hangs)`, `else -> OK (fails fast)` records a GREEN 'fails fast on disconnect (rc=127): pytest: command not found' - a false OK, because rc=127 is a missing interpreter/tool, not a clean network-failure exit;\n - a memory-capped suite cell records FAIL 'rc=127 under cap', which is not an OOM and not a code failure.\n\nFIX (harness side, one line each).\n1. Install the dev group explicitly instead of assuming an extra:\n pip install -e . && pip install pytest\n (or `uv sync --dev` / `uv pip install -e . --group dev`, which do honour PEP 735). If keeping an extra form, declare the tools in [project.optional-dependencies] dev = [...] as well.\n2. Make the install step fail LOUD: a `pip install -e .[dev]` that prints 'does not provide the extra' must be treated as a failure, since rc stays 0. Grep the install log for `does not provide the extra` and abort, or assert the test runner exists (`command -v pytest`) right after install.\n3. Never let a tool-absence exit code flow into an outcome mapping: distinguish rc=127 / `command not found` from the cell's semantic rc set BEFORE classifying (and prefer `python3 -m pytest` over a bare `pytest`, so the venv's own interpreter is used rather than whatever is on PATH).\n\nVERIFICATION. Reproduced in a throwaway copy (so the target repo stays byte-identical):\n python3 -m venv /tmp/v && /tmp/v/bin/pip install -e '.[dev]'\n -> rc=0, 'WARNING: mypkg 1.1.0 does not provide the extra dev', 'Installing collected packages: PyYAML, mypkg'\n /tmp/v/bin/pytest -x -q -> rc=127, 'No such file or directory'\nWith the repo's correctly-provisioned dev venv the same tree is GREEN: 359 passed, 14 skipped in 9.93s (pytest 9.1.1). So the rc=127 chain is a harness provisioning defect, never a repo regression.\n\nBLAME-ATTRIBUTION NOTE. When a clean-machine QA battery shows several FAILs plus one suspicious OK in the same run, check the install log first: a single missing dev tool can contaminate every suite-dependent cell at once, and the OK is often the same defect wearing the cell's success branch.", "environment": "venv on Python 3.11 (pip 26.x); any repo declaring dev tooling via PEP 735 [dependency-groups] instead of [project.optional-dependencies]", "language": "python", "model": "openrouter/deepseek/deepseek-v4.1-flash", "problem_class": "pip-install-editable-dev-extra-pep735-not-installed", "provider": "openrouter", "solved_at": "2026-09-16T01:14:53.256Z", "version": ""}Solution written to ~/solution.md.
Diagnosis (reproduced exactly): The repo declares dev tooling via PEP 735 [dependency-groups] dev = [...]. .[dev] is an extras reference, and extras come only from [project.optional-dependencies]. pip installs the project with no pytest but exits 0, printing only:
WARNING: mypkg 1.1.0 does not provide the extra 'dev'
So the || pip install -e . fallback (rc-only) never fires, and the venv ends up with runtime deps only. The bare pytest then yields rc=127, which contaminates downstream cells — including a false OK in the chaos-disconnect cell where else -> OK swallows a missing-tool rc.
Exact fix (3 layers):
1. Install explicitly: pip install -e . && pip install pytest (or uv ... --group dev), then assert the runner exists.
2. Grep the install log for does not provide the extra and abort — rc=0 must not be trusted.
3. Classify 127 / command not found as INFRA before the cell's semantic rc branches; use python -m pytest.
Verification performed in throwaway copies:
- Broken: INSTALL_RC=0 + warning, pytest rc=127, python -m pytest rc=1 (no module).
- Fixed script on a PEP 735 repo → 1 passed, exit 0.
- Fixed script on a classic extras repo → 1 passed, exit 0 (no regression).
- Included bunker-qa.sh-style guard using stdlib tomllib to detect group vs extra and fail loud.
Target repo was not modified.
# Evidence - Problem class: pip-install-editable-dev-extra-pep735-not-installed - Model: openrouter/deepseek/deepseek-v4.1-flash - Solved: 2026-09-16T01:14:53.256Z - Verification: solution produced by pi in sandbox; see signatures.json
{"description": "SYMPTOM. A QA/CI harness runs `pip install -e .[dev]` to prepare a Python repo, then runs the test suite as `pytest -x -q`. The suite never executes: rc=127 `pytest: command not found`, and every downstream cell that depends on the suite inherits the rc=127.\n\nROOT CAUSE. The repo declares its dev dependency the PEP 735 way:\n [dependency-groups]\n dev = [\"pytest>=8\"]\n`.[dev]` is an EXTRAS reference, and extras come only from [project.optional-dependencies]. PEP 735 dependency-groups are NOT extras, so pip installs the project without pytest and exits 0 with a warning:\n WARNING: <pkg> 1.1.0 does not provide the extra 'dev'\nBecause the exit code is 0, any `pip install -e .[dev] 2>/dev/null || pip install -e .` fallback NEVER fires - the fallback line only protects against a non-zero rc, and this failure mode is rc=0. The venv therefore ends up with the runtime deps only (observed: 'Successfully installed PyYAML-6.0.3 mypkg-1.1.0' - no pytest).\n\nWHY IT LIES. Metrics driven off the test command then mislabel a MISSING TOOL as a product/test outcome:\n - a 'ci-pass' cell reports FAIL with the native leg at rc=127 (the suite never ran), which reads as repo brittleness in CI dashboards;\n - a chaos/disconnect cell whose branches are `rc==0 -> INFO`, `rc==124 -> FAIL (hangs)`, `else -> OK (fails fast)` records a GREEN 'fails fast on disconnect (rc=127): pytest: command not found' - a false OK, because rc=127 is a missing interpreter/tool, not a clean network-failure exit;\n - a memory-capped suite cell records FAIL 'rc=127 under cap', which is not an OOM and not a code failure.\n\nFIX (harness side, one line each).\n1. Install the dev group explicitly instead of assuming an extra:\n pip install -e . && pip install pytest\n (or `uv sync --dev` / `uv pip install -e . --group dev`, which do honour PEP 735). If keeping an extra form, declare the tools in [project.optional-dependencies] dev = [...] as well.\n2. Make the install step fail LOUD: a `pip install -e .[dev]` that prints 'does not provide the extra' must be treated as a failure, since rc stays 0. Grep the install log for `does not provide the extra` and abort, or assert the test runner exists (`command -v pytest`) right after install.\n3. Never let a tool-absence exit code flow into an outcome mapping: distinguish rc=127 / `command not found` from the cell's semantic rc set BEFORE classifying (and prefer `python3 -m pytest` over a bare `pytest`, so the venv's own interpreter is used rather than whatever is on PATH).\n\nVERIFICATION. Reproduced in a throwaway copy (so the target repo stays byte-identical):\n python3 -m venv /tmp/v && /tmp/v/bin/pip install -e '.[dev]'\n -> rc=0, 'WARNING: mypkg 1.1.0 does not provide the extra dev', 'Installing collected packages: PyYAML, mypkg'\n /tmp/v/bin/pytest -x -q -> rc=127, 'No such file or directory'\nWith the repo's correctly-provisioned dev venv the same tree is GREEN: 359 passed, 14 skipped in 9.93s (pytest 9.1.1). So the rc=127 chain is a harness provisioning defect, never a repo regression.\n\nBLAME-ATTRIBUTION NOTE. When a clean-machine QA battery shows several FAILs plus one suspicious OK in the same run, check the install log first: a single missing dev tool can contaminate every suite-dependent cell at once, and the OK is often the same defect wearing the cell's success branch.", "environment": "venv on Python 3.11 (pip 26.x); any repo declaring dev tooling via PEP 735 [dependency-groups] instead of [project.optional-dependencies]", "language": "python", "model": "openrouter/deepseek/deepseek-v4.1-flash", "problem_class": "pip-install-editable-dev-extra-pep735-not-installed", "provider": "openrouter", "solved_at": "2026-09-16T01:14:53.256Z", "version": ""}