AutoPub — Publish Python Package Releases to PyPI Upon Pull Request Merge

AutoPub

AutoPub enables project maintainers to release new package versions to the Python Package Index (PyPI) simply by merging pull requests. Intended for use with continuous integration (CI) systems such as CircleCI or Travis CI, AutoPub streamlines the package release process by automating an otherwise manual, tedious, and error-prone series of steps.

The Problem

A significant source of friction in software development is packaging and publishing new releases. At a minimum, somebody has to sift through the commits and write a change-log, increment the version number in one or more files, commit and tag the new version number, create a new release (e.g., on GitHub), and then finally publish the package to PyPI. And usually only one or two people have the access necessary for this last critical step, creating a choke-point that often needlessly blocks the release process.

The unfortunate result is an infrequent release cadence. New features and bug fixes are sitting right there in the master branch, but hardly anybody is benefiting from them because they aren’t in a shipped release yet.

The Solution

Thankfully, there’s a better way: a continuous release process where new versions are auto-published via pull requests — without any manual monkeying.

In this environment, all pull requests must include a release file that describes the changes within. This file must also include whether the new version should be a major, minor, or patch release. Let’s look at an example RELEASE.md file:

Release type: patch

Ensure prefixed tag (not the bare version) is used when tagging commits.

When a maintainer decides that a given pull request conforms to project standards and merges it, the CI system invokes AutoPub, which looks for the release file in the master branch. If a release file hasn’t been included along with the pull request, the deployment stage of the build will be skipped. Otherwise, AutoPub uses the release file to prepend the description to the change-log and increment the version number, and then commits, tags, builds, and publishes the new release to GitHub and PyPI.

Benefits

Empowering anyone to issue a new release by submitting a pull request? At first glance, it seems like an outlandish idea. Upon further inspection, however, the benefits become clear.

With almost no human input, every code contribution results in a new release in a matter of minutes. Every feature and bug-fix has its own release, without anyone having to remember to package and publish a new version. Plus, if a bug is found, it’s now much easier to trace it to a specific release version.

Perhaps the best part is that all contributors get to issue their own releases. What better way to welcome new contributors than to reward them with a dedicated release composed entirely of their own work?

Release Early and Often

Do you want to automate packaging for projects you maintain? The best way to start auto-publishing packages is to look at how AutoPub publishes itself via CircleCI. Because of course it does!

For those who don’t mind the extra hoops required by Travis and who don’t want to switch to a more modern CI system, have a look at how Pelican releases are published via AutoPub and Travis.

What if you aren’t a maintainer, but you need a bug-fix to be shipped for a project that hasn’t had a new version released in a while? Create an issue in the project repository, point the maintainers to this page, and ask them to consider making their lives easier by automating package releases. Even better, help them out by submitting a pull request that adds AutoPub to the repository’s existing CI flow! 🚀

Need Help?

If the above examples aren’t enough to get you going, or if you have any questions about AutoPub, please don’t hesitate to get in touch!

Kudos

Many thanks to Marco Acierno and Patrick Arminio. Without their related deployment automation work on the Strawberry GraphQL library, AutoPub would not exist.