Skip to content

Rename crate to sqlrite-engine on crates.io#17

Merged
joaoh82 merged 1 commit intomainfrom
fix/rename-crate-to-sqlrite-engine
Apr 23, 2026
Merged

Rename crate to sqlrite-engine on crates.io#17
joaoh82 merged 1 commit intomainfrom
fix/rename-crate-to-sqlrite-engine

Conversation

@joaoh82
Copy link
Copy Markdown
Owner

@joaoh82 joaoh82 commented Apr 23, 2026

Why

The v0.1.1 canary release failed at cargo publish with a 403:

error: failed to publish sqlrite v0.1.1 to registry at https://crates.io.
Caused by: the remote server responded with an error (status 403 Forbidden): this crate exists but you don't seem to be an owner.

The sqlrite name on crates.io was already taken by an unrelated project (RAG-oriented SQLite wrapper). sqlrite-engine is available, so this PR renames the published package and paves the way for a v0.1.2 canary retry.

What changes

  • Root Cargo.toml: [package] name = "sqlrite-engine". The [lib] name = "sqlrite" and [[bin]] name = "sqlrite" are unchanged — downstream code still writes use sqlrite::… and the REPL is still sqlrite.
  • All workspace-member engine deps use the package = key so the import alias stays sqlrite:
    sqlrite = { package = "sqlrite-engine", path = "" }
    This touches sqlrite-ffi, sdk/python, sdk/nodejs, sdk/wasm, desktop/src-tauri.
  • release.yml: cargo publish -p sqlrite-engine, updated crates.io URL + TOML snippet in the per-release body, plus umbrella release body's crates.io link.
  • Docs: release-plan.md, roadmap.md, embedding.md updated with the new crate name + the reason for the rename.

What doesn't change

  • Published tag names (sqlrite-vX.Y.Z) — they reference the product, not the crate name.
  • Rust source code — zero .rs files touched.
  • PyPI / npm / Go module names (those are independent registries, no conflicts).

Tags from the failed v0.1.1 canary

sqlrite-v0.1.1, sqlrite-ffi-v0.1.1, v0.1.1 already exist on main (the tag-all step ran before publish-crate failed). Per the never-reuse-a-tag policy, they stay; the retry canary bumps to v0.1.2.

Test plan

  • cargo check --workspace --exclude sqlrite-python --exclude sqlrite-nodejs — clean
  • cargo check -p sqlrite-python -p sqlrite-nodejs — clean
  • cargo check inside sdk/wasm/ — clean (unrelated unused-mut warnings pre-exist)
  • cargo test -p sqlrite-engine --lib — 162 passed
  • CI runs on this branch
  • After merge: dispatch release-pr.yml at 0.1.2 → review Release PR → merge → approve release env → watch sqlrite-engine 0.1.1wait, 0.1.2 — appear on crates.io

🤖 Generated with Claude Code

The `sqlrite` crate name on crates.io was already taken by an
unrelated project (RAG-oriented SQLite wrapper), which made the
v0.1.1 canary's `cargo publish` step fail with a 403. Rename the
published package to `sqlrite-engine`, keep the [lib] name and
[[bin]] name as `sqlrite` so downstream Rust code continues to
write `use sqlrite::…` with no change.

Workspace members depend on the engine via:

    sqlrite = { package = "sqlrite-engine", path = "…" }

which keeps the import alias stable across the FFI shim, the
Python / Node.js / WASM SDKs, and the Tauri desktop app.

Also updates release.yml — `cargo publish -p sqlrite-engine`, the
per-release body's crates.io URL + TOML snippet, and the umbrella
release body's crates.io link — plus docs (release-plan, roadmap,
embedding) to match.

Per the never-reuse-a-tag policy, tags sqlrite-v0.1.1 /
sqlrite-ffi-v0.1.1 / v0.1.1 (created during the failed canary)
stay on main; the retry canary cuts v0.1.2.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@joaoh82 joaoh82 merged commit ee72ddb into main Apr 23, 2026
16 checks passed
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