Release Notes - Versions 0.12.x

Version 0.12.6

Bugs Fixed

Version 0.12.5

Bugs Fixed

Version 0.12.4

Bugs Fixed

Version 0.12.3

Bugs Fixed

Version 0.12.2

Bugs Fixed

Version 0.12.1

Bugs Fixed

Known Issues

Sphinx in sphinx-plugin has issues on Windows/Python 2.7 combination correctly interacting with symlinks that point to non-existent paths.

Version 0.12.0

Version 0.12.0 is a major backwards-compatible release (hence the minor version bump) bringing a large number of backwards-compatible rewrites to PyBuilder.



  • PyBuilder now uniformly supports and tests on Linux, OSX and Windows for all OS-independent features.
  • PyBuilder no longer has any direct dependencies and therefore doesn’t pollute the Python environment it is installed in.
  • PyBuilder now uses multiple tiers of Python Virtual ENVironments (venvs) to provide dependency isolation for PyBuilder and for different stages of the build process. The venvs are programmatically available to the plugins via the Reactor and are structured as follows:
    • system - the environment that launched the PyBuilder. Currently it is used as a seed environment for all of the following and is otherwise never modified:
      • pybuilder - this is a venv that is created internally inside PyBuilder Reactor during the initialization process and is located in the $basedir/.pybuilder/plugins directory. Environments are further distinguished by Python type and version names allowing the same project to be built with multiple Python flavors and versions, e.g.:

        pybuilder venv is used to install remote plugins and plugin dependencies used by the PyBuilder project and hosts all of the tooling.

      • python.core plugin is responsible for managing additional runtime venvs. By default PyBuilder creates the following venvs in $dir_target/venv:
        • build - venv that is used to deploy build-time and run-time dependencies and to run unit tests.
        • test - venv that is used to deploy run-time dependencies only and is used for running integration tests.
  • The following projects were internally vendored into PyBuilder:
  • PyBuilder intercepts project descriptor module loading/import process to reduce the number of pip install invocations. Thus dependency installations will be batched and installed lazily as much a possible reducing total environment preparation times.
  • Offline mode allows PyBuilder to function in the absence of Internet connectivity, provided the PIP artifacts are available in cache and/or otherwise already satisfied in the venvs.
  • A Remote framework similar to Java RMI was created for PyBuilder that allows remote method invocation and runtime data serialization with minimal boilerplate (i.e. with automatic Proxy creation) and utilizing a single communication channel with no additional threads. This dramatically simplifies writing of remote tooling for PyBuilder and guarantees that PyBuilder module loading is not affected by the remote tools and vice versa.
  • Windows text colorization added.
  • PyBuilder now supports PEP-517, i.e. pyproject.toml can be both generated for the managed projects and is used to install PyBuilder itself from the source tree.

Unit Tests

All unit tests now run execute in a fresh separate process and communicate remotely with PyBuilder reporting results. This provides full test isolation and prevents non-reproducible test results if PyBuilder loads modules that are later unit tested.

Unit tests run in the build venv which contains build-time and run-time dependencies.

Integration Tests

Integration tests run in the test venv which contains run-time dependencies only. Integration tests now integrate with coverage plugin when coverage is enabled.


Cram tests now integration with coverage plugin when coverage is enabled.


Coverage has been completely rewritten and converted into a pluggable infrastructure for other plugins:

  • Covered code modules are no longer imported by PyBuilder and therefore coverage is never affected by it.
  • Unit test, integration test, and cram plugins integrate with and request coverage.
  • Coverage now only reruns the tasks that request coverage as opposed to restarting entire task chains.
  • Coverage is upgraded to 5.x and therefore now uses new Coverage sqlite storage format.

New Plugins

  • Vendorizer plugin.
  • Coveralls plugin.

Bugs Fixed

#84, #508, #529, #532, #606, #607, #620, #623, #638, #644, #649, #650, #657, #658, #660, #668, #675, #676, #685, #686

Known Issues

  • While, technically, PyPy is fully supported, different versions of PyPy stall/deadlock(?) for unknown reasons.
    Furthermore, PyPy has bugs related to object finalization and resultant issues with sqlite in Coverage. Your mileage with PyPy may vary.
  • Cram coverage registers normally but due to the way Coverage configuration is transferred between Python processes there will be no Coverage will be recorded. This will be resolved once Coverage library is modified to not require a coverage config file.
  • Integration test parallelization is temporarily disabled due to threading limitations of the Remote framework. Sequential integration testing still works.
  • While PyBuilder itself no longer requires any particular version of PIP or setuptools to function, PEP-517 doesn’t honor pyproject.toml’s backend-path until PIP version 20.x. If you want to install PyBuilder from the source tree you must upgrade PIP to at least version 20.0.0 or use PIP prior to version 19.0.0.