1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
[]
# Phase 7g.1 — natural-language → SQL via an LLM provider.
#
# This crate is intentionally kept separate from `sqlrite-engine` so
# the engine stays pure-SQL with no HTTP / TLS / async dependencies.
# Anyone embedding SQLRite who doesn't need `ask()` (the WASM SDK,
# read-only build-time tooling, lean embeddings) can ignore this
# crate entirely.
#
# Published to crates.io as `sqlrite-ask`. Joins the lockstep release
# wave (`sqlrite-ask-vX.Y.Z` tag) — see `docs/release-plan.md`.
= "sqlrite-ask"
= "0.1.18"
= ["Joao Henrique Machado Silva <joaoh82@gmail.com>"]
= "2024"
= "1.85"
= "Natural-language → SQL adapter for sqlrite-engine. Anthropic-first; OpenAI / Ollama follow-ups."
= "https://github.com/joaoh82/rust_sqlite"
= "MIT"
[]
= "sqlrite_ask"
= "src/lib.rs"
[]
# Engine — for `Connection`, `Database`, `Table`, `DataType`. We
# introspect `Database.tables` directly to build the schema dump
# the LLM sees; we don't go through the SQL surface (SELECT against
# `sqlrite_master` would also work but the typed walk is cheaper +
# more robust against future schema-catalog renames).
#
# `package = "sqlrite-engine"` because the crate publishes under that
# name on crates.io (the `sqlrite` name was taken on the registry —
# see Phase 6d retrospective). The import alias `sqlrite` keeps
# `use sqlrite::…` working in this crate's source.
#
# `default-features = false` skips the engine's `cli` (rustyline +
# clap + env_logger) and `file-locks` (fs2) features — sqlrite-ask
# never spawns a REPL or opens a database itself; the caller passes
# in an already-opened `&Connection`. Avoids pulling those deps
# transitively into anyone who uses sqlrite-ask without the engine
# REPL.
#
# **`version = "0.1"` is required for `cargo publish`.** Without a
# version requirement on a path-dep, `cargo publish` rejects the
# manifest with:
#
# error: failed to verify manifest at sqlrite-ask/Cargo.toml
# Caused by:
# all dependencies must have a version requirement specified
# when publishing.
# dependency `sqlrite-engine` does not specify a version
#
# That's the exact error v0.1.17 hit on the first attempted publish
# (publish-ask job). `sqlrite-ffi` doesn't need this because it
# never publishes to crates.io — it ships as GitHub Release
# tarballs only. `sqlrite-ask` is the first crate-besides-the-
# engine that actually goes to the registry.
#
# Why caret `"0.1"` rather than the exact pinned version: the
# whole 0.1.x line is lockstep-released, so any 0.1.y on crates.io
# is compatible with sqlrite-ask 0.1.x. Caret avoids touching this
# line every release. Bump to `"0.2"` at the next major (whenever
# Phase 7 closes); same for 1.0.
= { = "sqlrite-engine", = "0.1", = "..", = false }
# JSON request/response shapes for the Anthropic Messages API. We
# could write the JSON by hand, but `serde_json` is already a
# transitive dep via the engine (Phase 7e — JSON column type), so
# this is free.
= { = "1", = ["derive"] }
= "1"
# Sync HTTPS client. `ureq` 2.x is pure-Rust + rustls — no system
# OpenSSL, no tokio, no async runtime. Per `ask()` call we make
# exactly one POST to api.anthropic.com, so the sync surface is a
# perfect fit. Rolling our own JSON types over ureq is ~120 LOC
# vs. ~400 LOC + tokio + reqwest::blocking via an SDK.
= { = "2", = ["json", "tls"] }
# Typed errors — same crate the engine uses for `SQLRiteError`, so
# the AskError variants compose cleanly with the engine's error
# tree via `#[from]`.
= "2"
[]
# Throwaway tiny localhost HTTP server for the integration test
# that exercises the real ureq path. Avoids hitting api.anthropic.com
# from CI (no network egress + no API key in test runners). Stays
# in `dev-dependencies` so it doesn't ship to consumers.
= "0.12"