[thekevinbot]

Fixes #958

Root cause

--version renders CARGO_PKG_VERSION of the dirsql core crate
(packages/rust/Cargo.toml, literal 0.2.7). putitoutthere rewrites that literal
in the crates.io lane only — the PyPI wheel and the npm addon are built from a
checkout where it is untouched, while their own manifests are rewritten to the real
release version. So every published wheel and npm package since 0.2.7 has printed
dirsql 0.2.7, whatever version it actually was.

There is no single literal to fix: the version has three correct sources, one per
publish lane.

Fix

lane	version source
crates.io binary	the core crate's CARGO_PKG_VERSION — unchanged
PyPI wheel	dirsql-py-ext's CARGO_PKG_VERSION, which maturin writes into the wheel and the module already exports as __version__ — now one constant, so the CLI and SDK cannot disagree
npm	packages/ts/package.json, read by the launcher and passed to the addon

The core gains cli::run_cli_with_version(argv, version); run_cli keeps its
signature and delegates with its own version. ~35 lines of code across five files;
the rest is the tests and the fragments the gates require.

packages/python/Cargo.toml's placeholder moves 0.2.7 → 0.0.1. It is a
placeholder either way (the release tooling rewrites it), but while it equalled the
core crate's, the python distcheck assertion below passed whether or not the CLI read
the right source — the coincidence that hid this.

Regression guard

dirsql-distcheck installs the published artifact and runs it; it asserted only that
the output contained the word "dirsql". Both flows now compare the exact string
against the version the package manager installed — the wheel filename for pip, the
installed package.json for npm.

RED first, on CI, both flows for the same reason
(python,
ts):

`dirsql --version` printed 'dirsql 0.2.7', expected 'dirsql 0.0.1'

E2E Verification

• Ran e2e suites locally for every affected SDK
• Python SDK e2e: pass (29 passed)
• TypeScript SDK e2e: pass (13 passed)
• Rust core e2e: pass (cargo test --workspace --features cli --no-fail-fast)
• packages/python/e2e-attestation.json refreshed
• packages/ts/e2e-attestation.json refreshed
• Command(s) run:
  • uv run python -m pytest tests/e2e/ -x -q (packages/python)
  • pnpm test:e2e (packages/ts)
  • cargo test --workspace --features cli --no-fail-fast
  • dirsql-distcheck node / dirsql-distcheck python — both OK
• Result summary: all green. Two sandbox-only failures in the Rust suite, neither
  related to this change: vtab.rs::unreadable_file_yields_null_content_… (the
  sandbox runs as root, so a chmod 000 file is still readable) and one
  sdk.rs::it_streams_watch_events watcher timing flake that passed on re-run.

Manual exercise (the point of the fix, not just the tests):

$ packages/python/.venv/bin/dirsql --version        dirsql 0.0.1   # == dirsql.__version__
$ node packages/ts/dist/cli/dirsql.js --version     dirsql 0.0.1   # == package.json
$ ./target/debug/dirsql --version                   dirsql 0.2.7   # the crate, unchanged
$ node packages/ts/dist/cli/dirsql.js query "SELECT COUNT(*) AS n FROM './'"
[{"n":557}]
$ node packages/ts/dist/cli/dirsql.js --nope        error: unexpected argument '--nope' found  (exit 2)

Changelog / Migrations

• Changelog fragment added under packages/<pkg>/changelog.d/ for each changed package (rust, python, ts)
• Migration fragment — judged not required: this is a bug fix that makes a wrong
  output correct, and no API breaks. The one visible shift is that a source
  checkout now reports 0.0.1 where the CLI used to say 0.2.7; published
  artifacts only gain the right number. Say the word and I'll add fragments.

Parity

PARITY.md updated. This restores parity rather than introducing drift: the
crates.io binary was already correct and both bindings now match it. The plumbing is
asymmetric on purpose (pyo3 bakes its crate version in, napi takes an optional
argument) because the manifest a publisher rewrites differs per lane; both surfaces
are launcher-facing, not SDK API.

Follow-up spotted, not fixed here

persist.rs / parsed_cache.rs stamp the same core-crate literal into the cache as
an invalidation key, so a wheel or addon writes 0.2.7 for every release — a core
change that alters parsing will not invalidate an existing cache. Same root cause,
different blast radius; worth its own issue rather than widening this PR.

[thekevinbot]

Closing unfixed — this belongs upstream, not here.

The stale --version string comes from putitoutthere bumping only the crate it builds. On the pypi and npm lanes that's packages/python and packages/ts/napi; the CLI's #[command(version)] lives in packages/rust, which ships inside both artifacts as a path-dep and never gets bumped. Filed as thekevinscott/putitoutthere#621 with the per-lane breakdown.

This PR worked around that by resolving the version from the host package's manifest at runtime and threading it into run_cli. It works, but it's a per-binding API change in every consumer to patch a build-time gap — and the same fix would have to be repeated in every other repo that hits this. The upstream fix also covers the part this PR didn't: persist.rs / parsed_cache.rs stamp that same stale literal as a cache-invalidation key, so published caches never invalidate across releases.

dirsql#958 stays open until upstream lands and dirsql re-releases. Branch claude/issue-958-q2loh3 is left in place if any of the distcheck assertions are worth salvaging separately.

---

Generated by Claude Code