At work, I recently switched our continous integration service from Travis CI to CircleCI. Travis was doing a fine job, but their paid plan is really quite expensive compared to Circle. This isn’t a problem for open source projects because both services offer a free tier for those situations, but the price difference for private repositories is significant.

The lowest priced tier available for private repositories at TravisCI is $129/month. Yeesh!

CircleCI offers 1 container for free to private repositories. Additional containers are $50/month, and builds can run tests in parallel across multiple containers. On the paid plan with multiple containers, our build was completing over 40% faster and at a savings of over 60%! More importantly, it was dead simple to set up. Dead simple as in, I basically had to do nothing.

As a result of this success, I decided to start migrating some of my personal repositories, both public and private, to CircleCI.

To the point . . . I recently released a small component of a larger project that I am working on, and I wanted to have my tests run on mutiple versions of Python (even though it’s not really needed from my own perspective), I had a little bit of frustration getting this accomplished on CircleCI. The problem has something to do with tox and pyenv not playing together very well, but it’s remedied by the tox-pyenv plugin written by Sam Stavinoha.

The solution ends up being quite easy. In my tox.ini I have . . .

envlist = py26,py27,py33,py34,py35

. . . and my circle.yml looks like this . . .

    - pip install tox tox-pyenv
    - pyenv local 2.6.8 2.7.10 3.3.3 3.4.3 3.5.0

The list of Python verions on the line with ‘pyenv local’, combined with the tox-pyenv plugin, clears up the confusion between tox and pyvenv so that tox knows which python to use for each version in its envlist.