The Python Package Index commonly known as PyPI is a repository of software for the Python programming langauge. Every time you run pip install $PACKAGE you are using PyPI. In this post, you will learn how to continously deploy your own Python packages to PyPI using git tags and CircleCI.

Over the last few weeks, I have been working on a Python wrapper for the CircleCI API. This project uses the same approach that we are going to be discussing here.


The only dependency that this approach requires outside of the standard Python library is the twine package.


This tutorial assumes the following things are true:

  1. You have an account on PyPI. If not, it is easy to get started. You can register here.
  2. You have an environment variable in your project settings called PYPI_PASSWORD that refers to your PyPI password.
  3. You have a Python package that follows standard packaging guidelines. If not, Python provides some excellent documentation on how to package and distribute projects.
  4. You are using git tags to create a release.
  5. You are using CircleCI 2.0 with workflows.

Release Workflow

A high level release workflow is described below.

  1. Once you are ready to cut a new release of your project, you update the version in and create a new git tag with git tag $VERSION.
  2. Once you push the tag to GitHub with git push --tags a new CircleCI build is triggered.
  3. You run a verification step to ensure that the git tag matches the version of my project that you added in step 1 above.
  4. CircleCI performs all of your tests (you have tests right?).
  5. Once all of your test pass, you create a new Python package and upload it to PyPI using twine.

Full Walkthrough

With all of those assumptions in place, and a high level overview in mind we are ready to dive into a real world example.

The file is the most important part of any Python package. It provides metadata for PyPI, handles all packaging tasks, and even allows you to add custom packaging-related commands. The file from our example project is shown below:

#!/usr/bin/env python
# -*- coding: utf-8 -*-
:copyright: (c) 2017 by Lev Lazinskiy
:license: MIT, see LICENSE for more details.
import os
import sys

from setuptools import setup
from setuptools.command.install import install

# version
VERSION = "1.1.1"

def readme():
    """print long description"""
    with open('README.rst') as f:

class VerifyVersionCommand(install):
    """Custom command to verify that the git tag matches our version"""
    description = 'verify that the git tag matches our version'

    def run(self):
        tag = os.getenv('CIRCLE_TAG')

        if tag != VERSION:
            info = "Git tag: {0} does not match the version of this app: {1}".format(
                tag, VERSION

    description="Python wrapper for the CircleCI API",
    author="Lev Lazinskiy",
        "Development Status :: 5 - Production/Stable",
        "Intended Audience :: Developers",
        "Intended Audience :: System Administrators",
        "License :: OSI Approved :: MIT License",
        "Operating System :: OS Independent",
        "Topic :: Software Development :: Build Tools",
        "Topic :: Software Development :: Libraries :: Python Modules",
        "Topic :: Internet",
        "Programming Language :: Python :: 3",
        "Programming Language :: Python :: 3.6",
        "Programming Language :: Python :: 3 :: Only",
    keywords='circleci ci cd api sdk',
        'verify': VerifyVersionCommand,

A couple of things to note:

  1. VERSION is set as a constant at the top of the file. This should always match your most recent git tag.
  2. The setup() function is fairly standard and provides all of the necessary metadata that PyPI needs.
  3. We have a custom command called verify which will ensure that our git tag matches our VERSION. We run this command as a part of our workflow to ensure that we are releasing the proper version.


Interesting parts of the CircleCI configuration file for this project are shown below. You can see the full file here.

Deployment Job

Once we have installed all of our project dependencies in preparation for packaging, we run the custom verify command (discussed in the previous section) to ensure that the git tag matches the version that we are about to release.

      - run:
          name: verify git tag vs. version
          command: |
            python3 -m venv venv
            . venv/bin/activate
            python verify

Next, we create a .pypirc file using the PYPI_PASSWORD environment variable that is set in our project settings.

      - run:
          name: init .pypirc
          command: |
            echo -e "[pypi]" >> ~/.pypirc
            echo -e "username = levlaz" >> ~/.pypirc
            echo -e "password = $PYPI_PASSWORD" >> ~/.pypirc

Then we create all of our packages.

      - run:
          name: create packages
          command: |
            make package

This project uses a Makefile for convenience. If you don’t want to use a Makefile you can run the commands manually in this section.

The commands to create a package are:

# create a source distribution
python sdist

# create a wheel
python bdist_wheel

Lastly, we upload the packages that we just created to PyPI using twine.

      - run:
          name: upload to pypi
          command: |
            . venv/bin/activate
            twine upload dist/*

Workflows Configuration

The deploy job that we configure is only trigged when the build is a git tag, and depends on our test job passing. The configuration for this type of setup is shown below:

  version: 2
      - build:
              only: /.*/
      - deploy:
            - build
              only: /[0-9]+(\.[0-9]+)*/
              ignore: /.*/


That’s it! Now every time that you push a new git tag for your project you will automatically create a new package and upload it to PyPI. This allows you to have a completely hands-off, and reproducible continous deployment pipeline. Most importantly, by using testing, continuous integration, and continous deployment you are able to ensure that the users of your package only get the highest quality package when they run pip install $YOUR_PACKAGE.