Simplon
Simplon is a delivery orchestrator for any software component that wants to follow a CI/CD flow. It gives you a framework for the tasks that make up that flow -- build, test, release, deploy, monitor -- and a way to bring in additional tasks of your own.
A component declares its commands in one manifest. Simplon assembles the CLI
from it, runs the steps, and knows nothing about the component itself. The
*ctl product family (netctl, infractl) is where it grew up and is its first
user -- an example of who uses it, not a limit on who can.
Using it
pip install simplon
The runtime dependencies are ranges, not exact pins: a product's own
requirements.txt is where exact versions belong, and a published package's
pins become its consumers' pins.
One extra: pip install simplon[typecheck] adds mypy, which the
test:typecheck-python gate runs. A product that does not declare that
command does not need it.
Starting a product
The very first launcher has a chicken-and-egg: a fresh product has no venv, so it has no Simplon to write its launcher with. Break it once by hand:
pipx run simplon init myctl --dir .
or pip install simplon into any venv and run simplon init myctl --dir . in
the product repo. Without --dir the skeleton lands in a new ./myctl/
subdirectory instead of at the repo root, so pass --dir . whenever the repo
is already the product. After that the generated myctl.sh carries itself, and
a later simplon init refreshes it.
Layout
src/simplon/ is the kernel: the import package, the thing that gets
published. orchestrator/ is Simplon's own product surface -- its manifest,
its commands -- because Simplon is a product of itself and builds and tests
itself with itself. The two layouts differ on purpose: the kernel uses the
conventional src-layout, while orchestrator/ has exactly the shape
simplon init writes into every product. If that shape is awkward, Simplon
feels it first.
Developing Simplon
Simplon builds and tests itself with itself:
pip install -e .
./simplon.sh test all
./simplon.sh build wheel
Releasing
Tag vX.Y.Z. The release workflow runs the tests, builds the wheel and
publishes to PyPI via Trusted Publishing. Releases are cut from tags only, so
every version points at a named commit.
1 maintainer
Release files for simplon 0.1.7
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| simplon-0.1.7-py3-none-any.whl | Python 3 | none | any | Details |
Release files / simplon-0.1.7-py3-none-any.whl
| Download URL | simplon-0.1.7-py3-none-any.whl |
|---|---|
| Size | 251.5 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
d80d11b221caa5b3b5047b5af2cc24e4fe509162ca1ec190c6eee6ee290cfcbd
|
|
BLAKE2b-256 checksum How to use checksums |
0926660fd3c7c5160be3246504a117b37fe09cbb91af4ee42b242a503a1ee8e7
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 4, 2026.
Transparency log
