Official plugins for the Pyxle framework — one repo, independently versioned packages.
| Package | What it is | Docs |
|---|---|---|
pyxle-db |
One explicit-SQL API over SQLite, PostgreSQL, and MySQL: portable ? placeholders, a uniform Row, checksum-tracked migrations, and the DatabaseLike contract other plugins build on. Not an ORM, on purpose. |
pyxle.dev/docs/plugins/pyxle-db |
pyxle-auth |
Email + password accounts with argon2id, sliding sessions, password-reset / email-verification flows, RBAC with wildcards, scoped API tokens, and request guards. Brings no UI and sends no email — hardened primitives only. | pyxle.dev/docs/plugins/pyxle-auth |
pip install pyxle-db # SQLite needs nothing else
pip install "pyxle-db[postgres]" # + asyncpg
pip install "pyxle-db[mysql]" # + asyncmy, cryptography
pip install pyxle-auth # pulls in pyxle-dbWire them up in pyxle.config.json and they handle their own lifecycle at
app startup — see each package's README for the two-line config.
This is a monorepo by design, because official plugins change together:
when pyxle-db grew its DatabaseLike protocol, pyxle-auth's
annotations and contract tests landed in the same commit, with one CI run
proving both sides. What stays independent is everything release-shaped:
- Versions — each package owns its
pyproject.tomlversion and its ownCHANGELOG.md. They drift apart as they should. - Releases — tags are per-package:
pyxle-db-v0.3.0releasespyxle-dband nothing else. Publishing a GitHub release with that tag triggerspublish.yml, which checks the tag against the package's declared version, builds just that package, and publishes it via PyPI trusted publishing through the package's ownpypi-<package>environment (PyPI pending publishers are unique per repo + workflow + environment, so per-package environments let every plugin register its own). Upgrading one plugin never touches another's PyPI history. - Issues — label with the package name.
CI (ci.yml) runs every package's suite on
Python 3.10–3.14 against real PostgreSQL 16 and MySQL 8 servers — the
multi-database claims in these packages are enforced, not aspirational. A
job fails if the live suites are ever silently skipped.
packages/
├── pyxle-db/ # each package is independently installable
│ ├── pyproject.toml # own version, deps, extras
│ ├── CHANGELOG.md # own release history
│ ├── pyxle_db/ # source (py.typed)
│ └── tests/ # own suite, incl. live-server conformance tests
└── pyxle-auth/
└── …same shape
python -m venv .venv && source .venv/bin/activate
pip install -e "packages/pyxle-db[postgres,mysql,dev]" -e "packages/pyxle-auth[dev]"
# unit + SQLite suites
(cd packages/pyxle-db && pytest)
(cd packages/pyxle-auth && pytest)
# the live-server suites run when these are set (CI always sets them):
export PYXLE_DB_TEST_POSTGRES_URL=postgresql://user:pass@127.0.0.1:5432/pyxle_test
export PYXLE_DB_TEST_MYSQL_URL=mysql://user:pass@127.0.0.1:3306/pyxle_test
ruff check packages/pyxle-db/pyxle_db packages/pyxle-auth/pyxle_authA new plugin is a new directory under packages/ — the release machinery
is generic and never needs editing:
packages/pyxle-<name>/with its ownpyproject.toml(version0.1.0),pyxle_<name>/source (ship apy.typedmarker),tests/,README.md,CHANGELOG.md, and a copy ofLICENSE.- Depend on
pyxle-framework, not on sibling plugins — unless the dependency is the point and documented (aspyxle-auth→pyxle-dbis). If your plugin needs a database, build against thepyxle_db.DatabaseLikecontract rather than a concrete class. - Wire your suite into
ci.yml. - Register a PyPI pending publisher
for the project: repo
pyxle-dev/pyxle-plugins, workflowpublish.yml, environmentpypi-pyxle-<name>(per-package environments keep the publisher tuples unique — PyPI requires that for pending publishers). Then release with apyxle-<name>-v0.1.0tag.
Vulnerability reports: security@pyxle.dev — see SECURITY.md for scope and response expectations. Please don't open public issues for security problems.
MIT, all packages.