feat(sql): make tree-sitter-sql a core dependency so default installs parse .sql (#1745)

[egarcia74]

Problem

A default uv tool install graphifyy / pipx install graphifyy contributes nothing for .sql files: the grammar lives behind the [sql] extra, so extract_sql bails with an error result and the #1745 warning is the only signal. SQL is a mainstream corpus language — schemas, migrations, stored procedures — and the failure mode is exactly the silent-skip shape #1745 was about: the operator sees a graph, just one with an entire language missing, and nothing tells them at install time.

We hit this in the field: a 391-file T-SQL data-migration corpus produced zero SQL object nodes on a fresh default install, and the fix was discoverable only by reading extractor source.

Why core rather than a better hint

tree-sitter-sql ships prebuilt abi3 wheels for every supported platform (Windows/macOS/Linux glibc+musl, x86_64+arm64) from 0.3.9, so promoting it keeps the default install toolchain-free — the reason tree-sitter-dm stays optional (#1104) does not apply here. The pin >=0.3.9,<0.4 carries an upper bound like every other grammar pin.

What this PR does

• tree-sitter-sql>=0.3.9,<0.4 moves from the [sql] extra into [project.dependencies], with a comment recording the wheel-availability rationale so the packaging policy stays legible.
• The sql extra is kept as an alias, so existing graphifyy[sql] install commands and scripts keep resolving; it now adds nothing beyond the core install.
• .sql is removed from _EXTRA_FOR_EXTENSION, so the .sql files silently extract 0 nodes when the [sql] extra is missing #1745 warning no longer sends users to a now-redundant extra; the extractor's missing-grammar error now says the install is incomplete and names the direct repair.
• README extras table updated; the sql row is replaced with a note explaining the move and that a normal upgrade is all an existing [sql]/pipx inject install needs.
• Version bump and changelog entry are deliberately not included — those look like maintainer release-commit territory here (chore: bump to 0.9.48), so comments and messages describe the grammar as a core dependency without naming a release.

Tests

New tests/test_sql_core_dependency.py pins the fix at the packaging layer so a regression (the dependency sliding back into an extra) fails the suite rather than resurfacing as a field report:

• the grammar must be in [project.dependencies], with an upper bound;
• .sql must not be mapped to an optional extra in the hint map;
• the dev environment itself must satisfy the dependency;
• an end-to-end table/view/procedure corpus must produce object nodes, contains/references/reads_from edges, and no dangling edge sources.

Existing SQL tests in tests/test_multilang.py convert from importorskip (which would silently skip the whole SQL surface if the grammar went missing — the exact failure mode this PR removes) to a hard import that fails instead. test_extract_warns_when_sql_grammar_missing now simulates genuine absence via both sys.modules and a find_spec monkeypatch, and asserts the new message names the direct repair, not the extra.

Validation

• Fresh-venv wheel install pulls tree-sitter-sql transitively; a SQL fixture produces nodes/edges with no extra or pipx inject involved; the missing-grammar warning path proven live by blanking the module.
• Full suite: 6 failed, 4835 passed, 28 skipped — the 6 (test_ollama.py, test_ollama_retry_cap.py) fail identically on unmodified v8 in this environment (local Ollama config), none touch SQL or packaging.
• ruff check graphify/ tests/: all checks passed.
• uv.lock regenerated.

Note

Independent of my companion PR #2960 fixing T-SQL routine recovery in graphify/extractors/sql.py; both touch tests/test_multilang.py, and a local merge of the two branches resolves trivially (we run the combined branch in production against the 391-file corpus).

[graphify-labs]

Graphify reviewed this change.

Worth a look — the grounded gate found no coupling regressions or blocking issues, but 1 advisory finding(s) below merit a look before merge.

Formal verification. No changes could be formally verified in this run.

---

Graphify review — findings

Promotes tree-sitter-sql from the sql extra to a core dependency in pyproject.toml, so .sql files extract on a default install (#1745); the sql extra stays as a harmless alias for old install scripts. Drops .sql from _EXTRA_FOR_EXTENSION and rewords extract_sql's missing-grammar error to name a broken install / direct reinstall rather than an optional extra, with README updated to match. Replaces the importorskip/_extract_sql_or_skip skips in the SQL tests with hard import tree_sitter_sql so absence fails instead of silently skipping.

Worth a look

• SQL dependency is only added to the lockfile, not the packaging source — uv.lock:1338 · Escalate · high
  • agreed by 2 of 2 members but NOT verified (no proof, no reproducing execution) — consensus is not a verdict; needs human review

Analysis details — impact, health, verification

Impact & health

Graphify review

Impact — 1897 functions depend on the 710 functions this change touches.

Health — this change adds coupling hotspots:

• new: extract() — 476 callers, 42 callees
• new: _rebuild_code() — 98 callers, 50 callees
• new: extract_xaml() — 19 callers, 17 callees
• new: extract_js() — 80 callers, 3 callees
• new: dispatch_command() — 2 callers, 119 callees
• new: _get_extractor() — 26 callers, 6 callees
• new: run_pipeline() — 8 callers, 13 callees
• new: collect_files() — 17 callers, 6 callees
• …and 25 more — each is listed as a finding

Verification — 1897 functions in the blast radius were not formally verified this run (proofs are advisory here).

Gate & verification

graphify gate

PASS — objectively clean (no health regressions, tests not run — proofs not run this pass (advisory)). Grounded, not self-assessed.

Advisory (not blocking):

• verification_scope: 1749 function(s) in the blast radius were not formally verified this run

Formal verification

Could not verify: Could not verify extract\_sql.

The verifier did not have enough to check extract\_sql, so it is saying so rather than guessing. No false assurance is the whole point.

Guarantee: No guarantee either way, this is an honest abstention, not a pass.

Note: Reason: parameter `path` is annotated `Path` — outside the synthesizable primitive/collection set

· 33 more finding(s) on lines outside this diff (see the check run).

[egarcia74]

On the Graphify-review finding ("SQL dependency is only added to the lockfile, not the packaging source", flagged high at uv.lock:1338): this doesn't match the diff. tree-sitter-sql>=0.3.9,<0.4 is added to [project.dependencies] in pyproject.toml (line 50 on the branch tip) — the lockfile change is downstream of that. The PR also ships test_tree_sitter_sql_is_a_core_dependency, which pins exactly this invariant by parsing pyproject.toml and fails if the dependency ever slides back into an extra; it passes on this branch. (The review itself notes the finding was "agreed but NOT verified".) Happy to adjust if a maintainer sees something I'm missing.