This project is merged with skeleton. What is skeleton? It’s the scaffolding of a Python project jaraco introduced in his blog. It seeks to provide a means to re-use techniques and inherit advances when managing projects for distribution.

An SCM-Managed Approach

While maintaining dozens of projects in PyPI, jaraco derives best practices for project distribution and publishes them in the skeleton repo, a Git repo capturing the evolution and culmination of these best practices.

It’s intended to be used by a new or existing project to adopt these practices and honed and proven techniques. Adopters are encouraged to use the project directly and maintain a small deviation from the technique, make their own fork for more substantial changes unique to their environment or preferences, or simply adopt the skeleton once and abandon it thereafter.

The primary advantage to using an SCM for maintaining these techniques is that those tools help facilitate the merge between the template and its adopting projects.

Another advantage to using an SCM-managed approach is that tools like GitHub recognize that a change in the skeleton is the same change across all projects that merge with that skeleton. Without the ancestry, with a traditional copy/paste approach, a commit like this would produce notifications in the upstream project issue for each and every application, but because it’s centralized, GitHub provides just the one notification when the change is added to the skeleton.


new projects

To use skeleton for a new project, simply pull the skeleton into a new project:

$ git init my-new-project
$ cd my-new-project
$ git pull gh://jaraco/skeleton

Now customize the project to suit your individual project needs.

existing projects

If you have an existing project, you can still incorporate the skeleton by merging it into the codebase.

$ git merge skeleton --allow-unrelated-histories

The --allow-unrelated-histories is necessary because the history from the skeleton was previously unrelated to the existing codebase. Resolve any merge conflicts and commit to the master, and now the project is based on the shared skeleton.


Whenever a change is needed or desired for the general technique for packaging, it can be made in the skeleton project and then merged into each of the derived projects as needed, recommended before each release. As a result, features and best practices for packaging are centrally maintained and readily trickle into a whole suite of packages. This technique lowers the amount of tedious work necessary to create or maintain a project, and coupled with other techniques like continuous integration and deployment, lowers the cost of creating and maintaining refined Python projects to just a few, familiar Git operations.

For example, here’s a session of the path project pulling non-conflicting changes from the skeleton:

Thereafter, the target project can make whatever customizations it deems relevant to the scaffolding. The project may even at some point decide that the divergence is too great to merit renewed merging with the original skeleton. This approach applies maximal guidance while creating minimal constraints.

Periodic Collapse

In late 2020, this project introduced the idea of a periodic but infrequent (O(years)) collapse of commits to limit the number of commits a new consumer will need to accept to adopt the skeleton.

The full history of commits is collapsed into a single commit and that commit becomes the new mainline head.

When one of these collapse operations happens, any project that previously pulled from the skeleton will no longer have a related history with that new main branch. For those projects, the skeleton provides a “handoff” branch that reconciles the two branches. Any project that has previously merged with the skeleton but now gets an error “fatal: refusing to merge unrelated histories” should instead use the handoff branch once to incorporate the new main branch.

$ git pull 2020-handoff

This handoff needs to be pulled just once and thereafter the project can pull from the main head.

The archive and handoff branches from prior collapses are indicate here:

refresh archive handoff
2020-12 archive/2020-12 2020-handoff


The features/techniques employed by the skeleton include:

Packaging Conventions

A pyproject.toml is included to enable PEP 517 and PEP 518 compatibility and declares the requirements necessary to build the project on Setuptools (a minimum version compatible with setup.cfg declarative config).

The setup.cfg file implements the following features:

Additionally, the file declares use_scm_version which relies on setuptools_scm to do two things:

Running Tests

The skeleton assumes the developer has tox installed. The developer is expected to run tox to run tests on the current Python version using pytest.

Other environments (invoked with tox -e {name}) supplied include:

A pytest.ini is included to define common options around running tests. In particular:

Relies on a .flake8 file to correct some default behaviors:

Continuous Integration

The project is pre-configured to run Continuous Integration tests.

Github Actions

Github Actions are the preferred provider as they provide free, fast, multi-platform services with straightforward configuration. Configured in .github/workflows.

Features include:

Continuous Deployments

In addition to running tests, an additional publish stage is configured to automatically release tagged commits to PyPI using API tokens. The release process expects an authorized token to be configured with each Github project (or org) PYPI_TOKEN secret. Example:

pip-run -q jaraco.develop -- -m jaraco.develop.add-github-secrets

Building Documentation

Documentation is automatically built by Read the Docs when the project is registered with it, by way of the .readthedocs.yml file. To test the docs build manually, a tox env may be invoked as tox -e docs. Both techniques rely on the dependencies declared in setup.cfg/

In addition to building the Sphinx docs scaffolded in docs/, the docs build a history.html file that first injects release dates and hyperlinks into the CHANGES.rst before incorporating it as history in the docs.

Cutting releases

By default, tagged commits are released through the continuous integration deploy stage.

Releases may also be cut manually by invoking the tox environment release with the PyPI token set as the TWINE_PASSWORD:

TWINE_PASSWORD={token} tox -e release