The ByteCode Ecosystem
How the 23 libraries fit together: which package builds on which, which interfaces they share, and how to combine them into real systems.
23
libraries and repos
9
shared interface families
64
classes mapped
7
runnable blueprints
depends onused by required pip extra toolingCtrl + scroll to zoom, drag to pan, Tab to walk the nodes
Pick a library
Hover a node to trace its lineage, click it to pin the details here. Each band is a layer: a package only depends on packages in the layers below it.
- Platform & services: Ready-made building blocks for AWS, APIs and infrastructure as code.
- Integrations: Clients for engines and providers: databases, SFTP, Redis, JWT, LLMs, Sentry.
- Frameworks & contracts: The interfaces the rest of the ecosystem implements: ETL, CDC, HTTP.
- Foundation: Zero or near-zero dependency primitives that everything builds on.
- Quality & delivery: How every package is tested, linted, released and deployed.
Reading the big picture
- One root. 13 of the 20 Python packages build on , directly or through another package. Its IFactory registry is why plugins written in one package show up in another.
- Contracts in the middle. core-etl and core-cdc define interfaces that core-aws, core-db and core-ftp implement. Switching a source or a target means switching a subclass, not a pipeline.
- Standalone pieces. core-sentry, core-algorithms, core-ciphers, core-datetime, core-dev-tools, core-tests depend on no other ByteCode package, so they drop into any project.
- One toolchain. Every package is tested, linted and released the same way: tests through manager.py (core-tests), linters, type checkers and scanners pinned by core-dev-tools, all run in CI by core-gitlab-templates and from Claude Code by core-claude.
Relations are taken from each package's pyproject.toml, its imports and its class hierarchy.