Hit this while reviewing #1610 and it produced a confidently wrong review, so it's worth a guard.
pyproject.toml pins:
tree-sitter-language-pack>=1.6,<2.0
A venv created before that pin was raised can still hold 0.13.0 and nothing complains — pytest runs, the suite passes, and parser behaviour differs materially from CI.
Why it matters
The Kotlin single-line-object misparse (#1600) is entirely grammar-dependent:
grammar 1.14.3 (pinned): object A { fun x() = 1 } -> infix_expression, 0 object_declaration captures
grammar 0.13.0 (stale) : object A { fun x() = 1 } -> object_declaration, captures = ['A']
So on a stale venv the bug does not reproduce, and #1610 looks like a no-op that can be closed. I nearly did exactly that. The reporter and I would have disagreed indefinitely with both of us running pytest and both seeing green.
This cuts the other way too: a parser fix developed against 0.13.0 could pass locally and fail in CI.
Suggested guards
Any one of these would have caught it:
- A session-scoped test assertion that the installed
tree_sitter_language_pack.__version__ satisfies the pin, failing loudly rather than skipping. Cheap and self-maintaining.
tests/run_tests.sh verifying installed versions against pyproject.toml before running (e.g. pip check plus an explicit version compare) — pip check alone does not catch this, since the stale package satisfies no broken dependency graph, it just predates the pin.
- Documenting a
pip install -e . --upgrade step in the contributing guide for anyone with an older checkout.
(1) is the most robust because it fails on the machine that's actually wrong.
Related: my local venv also had codegraphcontext 0.4.16 installed while the repo was at 0.5.7, which made cgc --version report 0.4.16 — a false positive for #1262. Same root cause: a long-lived venv drifting from the repo.
Hit this while reviewing #1610 and it produced a confidently wrong review, so it's worth a guard.
pyproject.tomlpins:A venv created before that pin was raised can still hold 0.13.0 and nothing complains —
pytestruns, the suite passes, and parser behaviour differs materially from CI.Why it matters
The Kotlin single-line-object misparse (#1600) is entirely grammar-dependent:
So on a stale venv the bug does not reproduce, and #1610 looks like a no-op that can be closed. I nearly did exactly that. The reporter and I would have disagreed indefinitely with both of us running
pytestand both seeing green.This cuts the other way too: a parser fix developed against 0.13.0 could pass locally and fail in CI.
Suggested guards
Any one of these would have caught it:
tree_sitter_language_pack.__version__satisfies the pin, failing loudly rather than skipping. Cheap and self-maintaining.tests/run_tests.shverifying installed versions againstpyproject.tomlbefore running (e.g.pip checkplus an explicit version compare) —pip checkalone does not catch this, since the stale package satisfies no broken dependency graph, it just predates the pin.pip install -e . --upgradestep in the contributing guide for anyone with an older checkout.(1) is the most robust because it fails on the machine that's actually wrong.
Related: my local venv also had
codegraphcontext0.4.16 installed while the repo was at 0.5.7, which madecgc --versionreport 0.4.16 — a false positive for #1262. Same root cause: a long-lived venv drifting from the repo.