Cargo.toml

[package]
name = "sqlrite-python"
version = "0.5.1"
authors = ["Joao Henrique Machado Silva <joaoh82@gmail.com>"]
edition = "2024"
rust-version = "1.85"
description = "Python bindings for the SQLRite embedded database engine. Ships the `sqlrite` module on PyPI."
repository = "https://github.com/joaoh82/rust_sqlite"
license = "MIT"

# PyO3 ships Python extension modules as cdylibs. The output is a
# platform-specific `.so` / `.pyd` that maturin bundles into a wheel.
#
# Named `sqlrite_pymod` at the Rust level so it doesn't collide with
# the root `sqlrite` crate's rlib; the PyO3 `#[pymodule]` attribute
# on `lib.rs` re-declares the import name as `sqlrite` on the Python
# side (that's what users `import sqlrite` against). rlib crate-type
# lets `cargo test -p sqlrite-python` compile the Rust-side tests
# without spinning up a Python interpreter.
[lib]
name = "sqlrite_pymod"
crate-type = ["cdylib", "rlib"]
path = "src/lib.rs"

[dependencies]
# `package = "sqlrite-engine"` — crates.io name — with an import alias
# of `sqlrite` so src/ code can keep saying `use sqlrite::…`. See root
# Cargo.toml for the full story on why the package name differs from
# the lib name.
sqlrite = { package = "sqlrite-engine", path = "../.." }

# PyO3 with the `abi3-py38` feature so one wheel works on every
# CPython 3.8+ release — no per-Python-version rebuild.
#
# `extension-module` tells PyO3 this is a runtime-loadable module,
# not a standalone binary that embeds Python; the linker then doesn't
# need `-lpython` at build time, which is what makes the manylinux
# wheel story simple.
pyo3 = { version = "0.23", features = ["extension-module", "abi3-py38"] }