Skip to content

Add the Sqlite3Shell CLI driver as a product#1

Merged
odrobnik merged 2 commits into
mainfrom
claude/add-sqlite3shell-driver
Jun 9, 2026
Merged

Add the Sqlite3Shell CLI driver as a product#1
odrobnik merged 2 commits into
mainfrom
claude/add-sqlite3shell-driver

Conversation

@odrobnik

@odrobnik odrobnik commented Jun 9, 2026

Copy link
Copy Markdown
Contributor

What

Adds a Sqlite3Shell library product: the argv parser plus the
dot-command / REPL engine that reproduces the sqlite3 command-line shell
(.tables, .schema, .dump, .import, .mode, -safe, …). It is
ArgumentParser-free and IO-agnostic — it reads, writes, and authorizes file
paths through ShellKit.Shell — so a host can drive it in-process on any
platform (Android included) and confine it to a sandbox.

Why

This is the shell layer that until now lived in
SwiftPorts (Sources/SQLiteKit/Sqlite3Shell).
The SDK was extracted here first; this brings the shell driver that sits on
top of it into the same repo, so there is a single source of truth and no
second copy to drift — see Cocoanetics/SwiftPorts#56. SwiftPorts now wraps
this product in an ArgumentParser command to ship the sqlite3 executable,
and SwiftBash registers it as a native builtin.

Changes

  • New Sqlite3Shell target + product (deps: SQLiteKit, ShellKit core
    no ArgumentParser, so no Android explicit-module-scanner cycle).
  • New ShellKit package dependency (pinned to main, like the others). SDK-only
    consumers of the SQLiteKit product never build this target or ShellKit
    into their link.
  • Sqlite3ShellTests moved here from SwiftPorts; exercises the port through
    the ArgumentParser-free Sqlite3Executable entry point, so it runs on the
    full CI matrix (macOS / Linux / Windows / Android emulator).
  • SwiftLint: the faithful CLI port (one dispatch switch, one REPL type) carries
    scoped disable:next directives at the few oversized declarations;
    file_length is allowed as a file-wide disable since it can't be scoped.

Verification

  • macOS: swift build --build-tests + swift test green — 107 tests
    (default), plus the --traits FTS5,SQLiteVec filtered suite. swiftlint --strict clean.
  • iOS: xcodebuild -scheme Sqlite3Shell -destination generic/platform=iOS
    BUILD SUCCEEDED (arm64-apple-ios16.0).
  • Linux / Windows / Android: covered by this repo's CI matrix on this PR.

Merge order

Merge this first. The companion PRs pin this package to main:
SwiftPorts (drops its own Sqlite3Shell, consumes this product) and SwiftBash
(repoints its sqlite3 builtin here).

🤖 Generated with Claude Code

The argv parser plus the dot-command / REPL engine that reproduces the
sqlite3 command-line shell (`.tables`, `.schema`, `.dump`, `.import`,
`.mode`, `-safe`, ...). It is ArgumentParser-free and IO-agnostic — it
reads, writes, and authorizes file paths through `ShellKit.Shell` — so a
host can drive it in-process on any platform (Android included) and
confine it to a sandbox.

This is the shell layer that previously lived in SwiftPorts
(Sources/SQLiteKit/Sqlite3Shell). Converging it here keeps the SDK and
its shell driver in one repo and removes the drift / duplicate-symbol
risk of a second copy (Cocoanetics/SwiftPorts#56). SwiftPorts now wraps
this product in an ArgumentParser command to ship the `sqlite3`
executable; SwiftBash registers it as a native builtin.

- New `Sqlite3Shell` library product + target (deps: SQLiteKit, ShellKit
  core — no ArgumentParser, so no Android module-scanner cycle).
- New ShellKit package dependency (pinned to main, like the others).
  SDK-only consumers of the `SQLiteKit` product never build this target
  or ShellKit into their link.
- Sqlite3ShellTests moved here from SwiftPorts; runs on the full matrix
  (macOS / Linux / Windows / Android emulator), exercising the port via
  the ArgumentParser-free `Sqlite3Executable` entry point.
- SwiftLint: the faithful CLI port (one dispatch switch, one REPL type)
  carries scoped `disable:next` directives; `file_length` is allowed as
  a file-wide disable since it can't be scoped.

Verified on macOS: build + 107 tests (default and --traits
FTS5,SQLiteVec), swiftlint --strict clean.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@chatgpt-codex-connector

Copy link
Copy Markdown

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

The iOS Simulator test of `-scheme SQLiteKit` failed with "Scheme
SQLiteKit is not currently configured for the test action" /
"Supported platforms ... is empty".

Root cause: the shell driver pulls in ShellKit -> swift-subprocess, and
swift-subprocess declares `platforms: [.macOS, .iOS("99.0")]` — the
`iOS("99.0")` sentinel means "iOS unsupported". xcodebuild folds
`Sqlite3ShellTests` (transitively -> ShellKit -> Subprocess) into the
autogenerated `SQLiteKit` scheme's test action, so the scheme's iOS
deployment floor becomes 99.0 and its supported-platform set goes empty.
The SDK itself still compiles + tests fine on iOS; only the test-action
scheme resolution breaks. `.swiftpm` is gitignored here, so an explicit
trimmed scheme isn't the project's convention.

Fix: the iOS job now *builds* both `SQLiteKit` and `Sqlite3Shell` for the
iOS device SDK (proving both products compile for iOS — the BUILD action
isn't poisoned) and no longer runs the simulator test. The actual SDK +
shell test suites run on macOS / Linux / Windows / Android via
`swift test` (all green).

Also drop the now-unused `SQLiteKit` dependency + `@testable import` from
`Sqlite3ShellTests` (it references no SQLiteKit symbols directly).

Verified locally: both `xcodebuild build -scheme {SQLiteKit,Sqlite3Shell}
-destination generic/platform=iOS` succeed; `swift test` still 107 green;
swiftlint --strict clean.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@odrobnik odrobnik merged commit 78922a8 into main Jun 9, 2026
16 of 17 checks passed
@odrobnik odrobnik deleted the claude/add-sqlite3shell-driver branch June 9, 2026 11:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant