PyBuilder is a build automation tool written in 100% pure Python that gives Python projects a dependency-based, plugin-driven build lifecycle, and it is aimed at Python developers and teams who want their builds defined in one place instead of scattered across ad-hoc scripts.

What it is

PyBuilder is a software build automation tool that lives in the Python ecosystem and is distributed through PyPI. It is written entirely in pure Python and mainly targets Python applications. Its design rests on the concept of dependency based programming: tasks declare what they need, and the build order follows from those declarations rather than from a hardcoded sequence. On top of that foundation sits a plugin mechanism that lets a project assemble a build life cycle in the style familiar from established Java build tools.

The concrete problem it solves is the absence of a structured, reproducible build life cycle in small and mid-sized Python projects. Rather than hand-writing shell scripts or chaining one-off commands for testing, coverage, and packaging, a project declares its plugins and a default task in a single build.py file, and PyBuilder runs the resulting graph. The recommended directory layout means a project that follows convention needs almost no configuration to get a working build, test, coverage, and publish pipeline.

Key capabilities

• Dependency based programming model: the build life cycle is derived from declared task dependencies rather than from a fixed script order.
• Plugin mechanism for constructing custom build life cycles, in the manner of established Java build tools.
• Ships with python.core, python.unittest, python.coverage, and python.distutils plugins out of the box, as shown in the README example.
• Build definition lives in a single build.py file, where plugins are registered with use_plugin and the default task is set through default_task.
• Supported runtimes cover Python 3.10, 3.11, 3.12, 3.13, 3.14, and 3.15, plus PyPy 3.10 and PyPy 3.11.
• Pure Python implementation, so the tool itself needs no native toolchain beyond the interpreter.
• Each release carries a git tag, and release notes are published on the project homepage alongside the plugin list.

Who uses it and how

• Python application teams that want a convention-based layout: follow the recommended directory structure, drop in a build.py, and get the full life cycle without further setup.
• Projects that need test and coverage reporting wired into the build, using the python.unittest and python.coverage plugins instead of separate invocations.
• Library and application maintainers who package and publish with the python.distutils plugin and a default_task of publish.
• Teams running builds in CI: the project's own pipeline runs through a GitHub Actions workflow named pybuilder.yml, and the status badge reflects builds on the master branch.
• Developers on alternative interpreters, since PyPy 3.10 and PyPy 3.11 are explicitly supported alongside CPython.

Getting started

Install from PyPI with pip install pybuilder; for a development build use pip install --pre pybuilder. Then create a build.py in a project that follows the recommended directory layout, register the plugins with use_plugin, and set default_task.

How it compares

The facts do not name any paid or proprietary product that PyBuilder replaces, and they do not name any peer Python build tool either, so it stands alone in this registry among Python build automation tools. Its only stated point of reference is the family of famous Java build tools, whose dependency-driven life cycles the plugin mechanism is explicitly modelled on. Beyond that analogy, no direct competitor is identified in the available material.

When to use it — and when not to

PyBuilder fits Python projects that want a declared, plugin-composed build life cycle and are willing to adopt the recommended directory layout, since that convention is what keeps the setup minimal. A self-hoster or adopter should note that no database, storage service, or mail server is mentioned as a runtime dependency, so operational overhead is limited to the Python interpreter and the tool's own pyproject installation. Two honest caveats stand out: the project does not promote git tags to GitHub releases, so consumers looking for formal release artifacts on GitHub will not find them, and the README is a short pointer to the homepage rather than a full manual, which means most documentation work happens off-repository. Anyone who needs a build tool with first-class GitHub release publishing, or who wants to avoid learning a plugin and life-cycle model, should look elsewhere.

$ pip install pybuilder

$ pip install --pre pybuilder

from pybuilder.core import use_plugin

use_plugin("python.core")
use_plugin("python.unittest")
use_plugin("python.coverage")
use_plugin("python.distutils")

default_task = "publish"