dirsql 0.4.13__tar.gz → 0.4.15__tar.gz

{dirsql-0.4.13 → dirsql-0.4.15}/Cargo.lock

@@ -500,7 +500,7 @@ dependencies = [
 
 [[package]]
 name = "dirsql-py-ext"
-version = "0.4.13"
+version = "0.4.15"
 dependencies = [
  "dirsql",
  "pyo3",

{dirsql-0.4.13 → dirsql-0.4.15}/PKG-INFO

@@ -1,7 +1,8 @@
 Metadata-Version: 2.4
 Name: dirsql
-Version: 0.4.13
+Version: 0.4.15
 Requires-Dist: tomli>=2 ; python_full_version < '3.11'
+Requires-Dist: bin-shim>=0.1
 Summary: Ephemeral SQL index over a local directory
 Keywords: sql,filesystem,directory,sqlite,index
 Author: Kevin Scott

dirsql-0.4.15/dirsql/cli/main.py

@@ -0,0 +1,66 @@
+"""Console-script entry point. Runs the CLI in-process through the compiled
+extension module — the same `_dirsql` the SDK imports — so the wheel ships one
+copy of the core instead of a `.so` plus a bundled binary (#738).
+
+All argv is forwarded transparently to the core, which owns subcommand
+dispatch; the launcher only prepends what the core cannot work out for itself
+(plugin config fragments, resolved extension paths).
+"""
+
+from __future__ import annotations
+
+import signal
+import sys
+
+from bin_shim import main as run_in_process
+
+from .discover_plugins.with_discovered_plugins import with_discovered_plugins
+from .resolve_config_extensions import with_resolved_extensions
+
+
+def _absorb_interrupt(*_args: object) -> None:
+    """Let the core's own shutdown decide the exit code on SIGINT.
+
+    signal-hook (which tokio uses) *chains*: it runs tokio's handler — which
+    drives `dirsql server`'s graceful shutdown, after which `run_cli` returns
+    0 — and then whatever handler was installed before it. CPython's default
+    is `default_int_handler`, which raises `KeyboardInterrupt`; that lands
+    after `run_cli` has already returned 0 and turns a clean shutdown into a
+    130. This handler occupies that slot without raising, so the core's exit
+    code is the one that survives, exactly as it does when the CLI is its own
+    process.
+
+    A signal arriving when the core is NOT handling signals still terminates:
+    `run_cli` is only reached with this installed, and it returns promptly for
+    every non-server command.
+    """
+
+
+def with_core_owned_signals(handler=signal.signal):
+    """Install `_absorb_interrupt` for SIGINT and return the prior handler."""
+    return handler(signal.SIGINT, _absorb_interrupt)
+
+
+def main(argv: list[str] | None = None) -> int:
+    if argv is None:
+        argv = sys.argv[1:]
+
+    # Discover installed plugins (CLI only) and inject their config fragments as
+    # `-c` flags before resolving extensions; then resolve any package-name
+    # extensions in a TOML config here (the core can't) as `--extension`
+    # flags. Both are no-ops when nothing applies.
+    try:
+        argv = with_discovered_plugins(argv)
+        argv = with_resolved_extensions(argv)
+    except Exception as exc:
+        print(f"dirsql: {exc}", file=sys.stderr)
+        return 1
+
+    previous = with_core_owned_signals()
+    try:
+        return run_in_process(argv=argv, module="dirsql._dirsql")
+    except Exception as exc:
+        print(f"dirsql: {exc}", file=sys.stderr)
+        return 1
+    finally:
+        signal.signal(signal.SIGINT, previous)

{dirsql-0.4.13 → dirsql-0.4.15}/packages/python/Cargo.toml

@@ -4,7 +4,7 @@ name = "dirsql-py-ext"
 # pypi/maturin handler can rewrite it via `write-version` before
 # `maturin build`. `pyproject.toml` declares `dynamic = ["version"]`
 # and maturin reads this field. Mirrors `packages/rust/Cargo.toml`.
-version = "0.4.13"
+version = "0.4.15"
 # abi3 note: the `abi3-py310` pyo3 feature (below) builds ONE stable-ABI
 # `cp310-abi3` wheel per platform that loads on every CPython >= 3.10
 # (matching `pyproject.toml`'s `requires-python = ">=3.10"`), instead of
@@ -22,7 +22,10 @@ name = "dirsql_py_ext"
 crate-type = ["cdylib", "rlib"]
 
 [dependencies]
-dirsql.workspace = true
+# `cli` is on so the extension module carries `dirsql::cli::run_cli`: the
+# console script calls it in-process instead of exec'ing a bundled binary
+# (#738), which is what lets `dirsql/_binary/` leave the wheel.
+dirsql = { workspace = true, features = ["cli"] }
 pyo3 = { version = "0.28", features = ["extension-module", "generate-import-lib", "abi3-py310"], optional = true }
 
 [lints.rust]

dirsql-0.4.15/packages/python/changelog.d/2026-08-04-cli-in-process.md

@@ -0,0 +1,3 @@
+**Changed** — the `dirsql` console script now runs **in-process** through the compiled extension module instead of `exec`ing a bundled binary. `_dirsql` is built with the core's `cli` feature and exports `run_cli`, which the launcher calls via [bin-shim](https://pypi.org/project/bin-shim/). Plugin discovery and config-extension resolution are unchanged and still run first. The Windows/POSIX split is gone — `os.execv` on POSIX and `subprocess.run` on Windows are replaced by one in-process call on every platform, so the two no longer drift.
+
+**Removed** — **BREAKING (packaging)**: the wheel no longer ships `dirsql/_binary/`. It held a standalone `dirsql` executable duplicating the core already present in the extension module; `pyproject.toml`'s `[tool.maturin].include` row and the release pipeline's pypi `bundle_cli` staging are both gone. `pip install dirsql && dirsql ...` and `uvx dirsql` behave exactly as before — verified across `--version`, a query, a SQL error (1), an unknown flag (2), and `dirsql server` + Ctrl-C (graceful shutdown, **0**). Anyone locating that binary by path must instead call `dirsql._dirsql.run_cli(argv)`, or install the Rust binary with `cargo install dirsql --features cli`. See [MIGRATIONS.md](../../MIGRATIONS.md). #738.

dirsql-0.4.15/packages/python/e2e-attestations/claude-737-cli-run-shim.json

@@ -0,0 +1,7 @@
+{
+  "command": "uv run python -m pytest tests/e2e/ -x -q",
+  "ran_at": 1785873153,
+  "exit_code": 0,
+  "commit": "c5f2a08d38a02c59dde741cddad42720e7efc003",
+  "branch": "claude/737-cli-run-shim"
+}

dirsql-0.4.15/packages/python/e2e-attestations/claude-738-pypi-in-process.json

@@ -0,0 +1,7 @@
+{
+  "command": "uv run python -m pytest tests/e2e/ -x -q",
+  "ran_at": 1785876908,
+  "exit_code": 0,
+  "commit": "ed7317d77304d37024796dfe1622cb33b1d4cae7",
+  "branch": "claude/738-pypi-in-process"
+}

dirsql-0.4.15/packages/python/e2e-attestations/claude-739-npm-in-process.json

@@ -0,0 +1,7 @@
+{
+  "command": "uv run python -m pytest tests/e2e/ -x -q",
+  "ran_at": 1785875579,
+  "exit_code": 0,
+  "commit": "7094ce9be3c13c0764176484e62b0aaa5a2d9c1d",
+  "branch": "claude/739-npm-in-process"
+}

dirsql-0.4.15/packages/python/e2e-attestations/claude-772-extension-without-config.json

@@ -0,0 +1,7 @@
+{
+  "command": "uv run python -m pytest tests/e2e/ -x -q",
+  "ran_at": 1785877241,
+  "exit_code": 0,
+  "commit": "83f767a7d90cefe1aa6ab136e36a739cfb5dc425",
+  "branch": "claude/772-extension-without-config"
+}

dirsql-0.4.15/packages/python/migrations.d/2026-08-04-cli-in-process.md

@@ -0,0 +1,63 @@
+# The wheel's CLI runs in-process; `dirsql/_binary/` is gone
+
+## Summary
+
+The `dirsql` console script no longer `exec`s a bundled binary. The extension
+module (`dirsql._dirsql`) is built with the core's `cli` feature and exports
+`run_cli`; the launcher calls it in this process via bin-shim. The wheel
+therefore ships one copy of the core — the extension module — instead of that
+module *plus* a standalone executable.
+
+## Required changes
+
+**For nearly everyone: none.** `pip install dirsql`, `uvx dirsql`, and the
+`dirsql` console script behave as before: same argv handling, same output,
+same exit codes.
+
+Action is needed only if you located the bundled binary by path — e.g.
+`importlib.resources.files("dirsql") / "_binary" / "dirsql"` — and executed it
+yourself:
+
+- Call `dirsql._dirsql.run_cli(argv)` instead. It returns an exit code rather
+  than terminating the process (`argv` excludes the program name).
+- If you need a standalone executable, `cargo install dirsql --features cli`
+  builds the same code.
+
+## Deprecations removed
+
+`dirsql/_binary/` is no longer part of the wheel. The
+`{ path = "dirsql/_binary/*", format = "wheel" }` maturin include row and the
+pypi `[package.bundle_cli]` release block are both removed.
+
+`dirsql.cli.binary_path` and `dirsql.cli.is_windows` are deleted — both existed
+only to locate and exec that binary.
+
+## Behavior changes without code changes
+
+- **The CLI shares the console script's process.** For `dirsql server` the
+  Python interpreter stays resident for the server's lifetime rather than
+  being replaced by `os.execv`.
+- **Windows and POSIX take the same path.** The `is_windows()` branch
+  (`subprocess.run` vs `os.execv`) is gone, so the platforms cannot drift.
+- **`dirsql server` + Ctrl-C still exits 0.** This needed care and is worth
+  recording. signal-hook (which tokio uses) chains to the handler installed
+  before it; CPython's `default_int_handler` raises `KeyboardInterrupt`, which
+  lands *after* `run_cli` has already returned 0 from its graceful shutdown
+  and which bin-shim then converts to 130. Measured: the naive wiring exits
+  **130** where the old `execv` path exits **0**. The launcher therefore
+  installs a non-raising SIGINT handler for the duration of the run so the
+  core's own exit code survives, and restores the previous handler afterward.
+  This keeps the wheel's behavior identical to before *and* matches the npm
+  launcher (#739), which also exits 0.
+
+## Verification
+
+```
+$ dirsql --version                              # 0   dirsql 0.2.7
+$ dirsql query "SELECT COUNT(*) AS n FROM './'" # 0   [{"n":2}]
+$ dirsql query "SELECT frobnicate()"            # 1   SQLite error: no such function
+$ dirsql --nope                                 # 2   error: unexpected argument
+$ dirsql server --port 7242 & kill -INT $!      # 0   graceful shutdown
+```
+
+Python e2e suite: 27 passed. Unit suite: 108 passed at 100% coverage.

{dirsql-0.4.13 → dirsql-0.4.15}/packages/python/src/lib.rs

@@ -446,6 +446,26 @@ mod python {
         }
     }
 
+    /// Run the `dirsql` CLI in this process and return its exit code.
+    ///
+    /// The console script calls this instead of exec'ing a bundled binary, so
+    /// the wheel ships one copy of the core rather than two (#738). `argv`
+    /// excludes the program name; the core prepends it for clap.
+    ///
+    /// Returns rather than exiting — the caller (bin-shim) owns the process
+    /// exit. Codes are ordinary status codes, never 130/143 (#737).
+    ///
+    /// The GIL is released for the duration: the CLI can run a long-lived
+    /// server, and holding the GIL would wedge every other Python thread in
+    /// the host for its lifetime.
+    #[pyfunction]
+    fn run_cli(py: Python<'_>, argv: Vec<String>) -> i32 {
+        let mut full = Vec::with_capacity(argv.len() + 1);
+        full.push("dirsql".to_string());
+        full.extend(argv);
+        py.detach(|| dirsql::cli::run_cli(full))
+    }
+
     #[pymodule]
     #[pyo3(name = "_dirsql")]
     fn py_dirsql_module(m: &Bound<'_, PyModule>) -> PyResult<()> {
@@ -454,6 +474,7 @@ mod python {
         m.add_class::<PyDirSQL>()?;
         m.add_class::<PyRowEvent>()?;
         m.add_class::<PyScanFailure>()?;
+        m.add_function(wrap_pyfunction!(run_cli, m)?)?;
         Ok(())
     }
 

dirsql-0.4.15/packages/rust/changelog.d/2026-08-04-cli-run-shim.md

@@ -0,0 +1,3 @@
+**Added** — `dirsql::cli::run_cli(argv) -> i32`, the CLI's single entry point, now public on the crate (behind `--features cli`). It parses an explicit `argv`, dispatches the same commands the binary always has, and **returns** its exit code rather than terminating the process: clap's `parse()` calls `std::process::exit` on `--help`, `--version` and usage errors, so `run_cli` parses fallibly and renders the result itself — same text, same streams, same codes, minus the exit. That makes the CLI callable from an embedding host (the pip/npm launchers, via their bindings) instead of only from a process of its own. Exit codes stay ordinary status codes and are never 130/143: a `SIGINT` to `dirsql server` still shuts down gracefully and returns 0, exactly as before.
+
+**Changed** — the 956-line `src/bin/dirsql.rs` (argument parsing, command dispatch, config/state loading) moved into `src/cli/run.rs`; the binary is now a shim that calls `run_cli` and exits with what it returns, so `cargo install dirsql --features cli` and every other entry path run the same code. Behavior is unchanged and was verified so: a capture harness recorded stdout, stderr and exit code for 23 invocations — every clap help/version/usage-error path, each subcommand, and the config/SQL/extension error paths — against binaries built before and after the move, and the two captures are byte-identical.

dirsql-0.4.15/packages/rust/changelog.d/2026-08-04-configless-extension.md

@@ -0,0 +1 @@
+**Fixed** — `--extension` is now honored when no `-c`/`--config` is given. The configless path (no config, no `--include-default`) short-circuited before extensions were applied, so `dirsql query "SELECT vec_version()" --extension <path>::<entry>` reported `no such function: vec_version` as though the flag had not been passed — and, worse, `--extension /nonexistent.so` exited **0**, silently succeeding on a load that never happened. Both now behave: the extension loads and a bad path fails with `failed to build the index: failed to load extension '<path>'` and exit 1, matching the with-config path. This mattered because loading an extension to query a path-table (`SELECT * FROM './'`) needs no config at all, and because the npm/pip launchers pass resolved `--extension` flags — a launcher-resolved extension was dropped whenever the user had no config. #772.

dirsql-0.4.15/packages/rust/src/bin/dirsql.rs

@@ -0,0 +1,46 @@
+//! The `dirsql` binary: a shim over [`dirsql::cli::run_cli`].
+//!
+//! Every packaging path runs the same code — `cargo install dirsql --features
+//! cli` compiles this shim, and the pip/npm launchers reach `run_cli` through
+//! their bindings. All argument parsing, dispatch and exit-code selection live
+//! in the library so none of it can drift per entry point.
+//!
+//! Only compiled with `--features cli`.
+
+use std::process::ExitCode;
+
+fn main() -> ExitCode {
+    // `run_cli` returns rather than exiting, so the process exit lives here.
+    ExitCode::from(exit_status(dirsql::cli::run_cli(
+        std::env::args().collect(),
+    )))
+}
+
+/// Narrow `run_cli`'s `i32` to the `u8` a process exit status actually
+/// carries. `run_cli` is `i32` for the binding boundary but only ever yields
+/// 0..=255; anything outside that range would be truncated by the OS anyway,
+/// so it is clamped to a generic failure rather than wrapped into a
+/// misleading code (a hypothetical 256 must not surface as success).
+fn exit_status(code: i32) -> u8 {
+    u8::try_from(code).unwrap_or(1)
+}
+
+#[cfg(test)]
+mod tests {
+    use super::exit_status;
+
+    #[test]
+    fn passes_through_the_codes_run_cli_produces() {
+        assert_eq!(exit_status(0), 0);
+        assert_eq!(exit_status(1), 1);
+        assert_eq!(exit_status(2), 2);
+        assert_eq!(exit_status(255), 255);
+    }
+
+    #[test]
+    fn clamps_out_of_range_codes_to_failure() {
+        // Truncating would turn these into 0 — a failure reported as success.
+        assert_eq!(exit_status(256), 1);
+        assert_eq!(exit_status(-1), 1);
+    }
+}

{dirsql-0.4.13 → dirsql-0.4.15}/packages/rust/src/cli/mod.rs

@@ -34,9 +34,11 @@ use crate::command::DEFAULT_COMMAND_TIMEOUT;
 pub mod execute;
 pub mod init;
 pub mod router;
+pub mod run;
 pub mod serialize;
 pub mod server;
 
+pub use run::run_cli;
 pub use server::{serve, serve_with_state};
 
 /// Re-export of the crate-level baked-in default config