pyproject.toml line 12 declares:
That is not true. poetry.lock resolves and installs on cp311 only. A contributor arriving on 3.12 or 3.13 is told the project supports them, runs poetry install, and watches it fail while building a package they have never heard of.
Measured (2026-08-22, wheel availability checked directly against the index)
| interpreter |
pyarrow 16.1.0 |
levenshtein 0.20.9 |
| cp311 |
yes |
yes |
| cp312 |
yes |
no |
| cp313 |
no |
no |
Two independent blockers:
Why it matters
CI runs 3.11 and the delivery's conda prefix is 3.11.15, so nothing in production or CI is affected. The cost is entirely at onboarding: the declaration is the first thing a new contributor reads and it points them at an interpreter the lock cannot serve. This repo's stated position is that things are declared rather than inferred (ADR-003) — a declared range wider than the one that works is the same defect in the other direction.
It also makes tests/test_locked_environment.py give wrong advice. That test prints "Run poetry install" as the remedy for drift, and its own design notes rule out reporting a remedy that cannot work. On 3.12+ it does exactly that. See C-104 in the risk register, updated with the same measurements.
Proposed fix
Narrow the declaration to what is true:
and say why in a comment, pointing at ingester3's levenshtein cap as the binding constraint, so the next person to widen it knows what to check first.
Widening it again is not a pyproject edit — it needs ingester3 to lift the levenshtein cap, and (for 3.13) #174's three-repo fixture re-vendor to land first. Those are the two named triggers.
Not urgent: no production or CI impact. Cheap and it stops lying.
pyproject.tomlline 12 declares:That is not true.
poetry.lockresolves and installs on cp311 only. A contributor arriving on 3.12 or 3.13 is told the project supports them, runspoetry install, and watches it fail while building a package they have never heard of.Measured (2026-08-22, wheel availability checked directly against the index)
pyarrow 16.1.0levenshtein 0.20.9Two independent blockers:
levenshteinis capped>=0.20,<0.21byingester3. No release in that range publishes a 3.12+ wheel, and the sdist build fails (scikit-build/CMake). This cap is upstream — not ours to lift here.pyarrow 16.1.0predates 3.13 and has no cp313 wheel. Our<17ceiling is deliberate and owned by pyarrow: lifting the <17 ceiling is a three-repo fixture re-vendor, not a dependency bump (C-72) #174 (C-72 byte-parity fixtures), so this one is a consequence of a decision we already took knowingly.Why it matters
CI runs 3.11 and the delivery's conda prefix is 3.11.15, so nothing in production or CI is affected. The cost is entirely at onboarding: the declaration is the first thing a new contributor reads and it points them at an interpreter the lock cannot serve. This repo's stated position is that things are declared rather than inferred (ADR-003) — a declared range wider than the one that works is the same defect in the other direction.
It also makes
tests/test_locked_environment.pygive wrong advice. That test prints "Runpoetry install" as the remedy for drift, and its own design notes rule out reporting a remedy that cannot work. On 3.12+ it does exactly that. See C-104 in the risk register, updated with the same measurements.Proposed fix
Narrow the declaration to what is true:
and say why in a comment, pointing at
ingester3'slevenshteincap as the binding constraint, so the next person to widen it knows what to check first.Widening it again is not a
pyprojectedit — it needsingester3to lift thelevenshteincap, and (for 3.13) #174's three-repo fixture re-vendor to land first. Those are the two named triggers.Not urgent: no production or CI impact. Cheap and it stops lying.