Download
Releases, PyPI, source archives and provenance.
The current release is v0.62.0. Every release is published three ways from the same commit: to PyPI, as a GitHub Release with source archives, and as a git tag.
Install it (recommended)#
You almost certainly want the packaged CLI rather than an archive:
uv tool install agent-container # or: pipx install agent-container
agent-container --version
- PyPI project: pypi.org/project/agent-container
- Full instructions, including the host side: Installation
Source code#
| What | Where |
|---|---|
| Clone | git clone https://github.com/ondrasek/agent-container.git |
| This release, tagged | v0.62.0 |
| Tarball | agent-container-0.62.0.tar.gz |
| Zip | agent-container-0.62.0.zip |
| All releases | github.com/ondrasek/agent-container/releases |
| Browse the tree | github.com/ondrasek/agent-container |
Pin a specific version instead of main:
git clone --branch v0.62.0 --depth 1 https://github.com/ondrasek/agent-container.git
You need a checkout on the host
A PyPI install is a complete client. But build needs a checkout as the
container build context, and up needs the image localhost/agent-container:latest
to exist locally — no prebuilt image is published to any registry. So the machine
that actually runs containers needs the source, one way or another.
Just the CLI, no install#
bin/agent-container is a single self-contained PEP 723
script. Given uv, it needs nothing else:
curl -O https://raw.githubusercontent.com/ondrasek/agent-container/v0.62.0/bin/agent-container
chmod +x agent-container
uv run --script ./agent-container --help
The --script form makes uv read the dependency metadata embedded in the file
and build an ephemeral environment for it.
Provenance#
Releases are built and published by GitHub Actions from the tagged commit, with no human in the loop and no stored PyPI token:
- PyPI uploads use OIDC Trusted Publishing, bound to this repository and to
the
publish.ymlworkflow specifically. - Distributions carry PEP 740 attestations, generated at publish time and verifiable on PyPI.
- The version is not chosen by hand. python-semantic-release derives it from
the Conventional Commits since the previous release, then bumps
pyproject.toml, writes the changelog, tags, and creates the GitHub Release. - Nothing ships red. The release workflow fires only after the full CI
pipeline — quality gate, pinned-interpreter pytest, build, and the
real-container acceptance suite — has passed on
main.
How releases reach this website#
This site is rebuilt automatically by the pages workflow after every release,
and on every push to main. It is generated from the repository's own markdown,
so the published documentation is always the documentation of the current
release. The version above is read from the tag at build time.
The release leg chains off the release workflow with workflow_run rather than
listening for release: [published], because
an event triggered by GITHUB_TOKEN never starts another workflow run
— and python-semantic-release, which creates the release, authenticates with
exactly that token. The alternative would be a personal access token: a standing
credential, which is the thing this whole project is built to avoid.
Version history#
The changelog is generated from the commit history. Pre-1.0, note one thing about how versions move:
| Commit type | Bump |
|---|---|
feat |
minor |
fix |
patch |
| breaking change | minor — while pre-1.0 |
A breaking change is therefore not visible in the version number. It is recorded in the commit body and surfaced in the changelog, which is why the contribution rules insist on it.
License#
Released under the MIT License.