The error we see from tox in the circle build logs says:

ERROR:   py32: InvocationError: Failed to get version_info for python3.2: pyenv: python3.2: command not found

The `python3.2' command exists in these Python versions:
  3.2
  3.2.5

EDIT: Got past this error, now the problem is tox is finding the wrong python binaries to use for a couple of the virtual environments. By this I mean e.g. specifying py31 with tox results in tox actually using python 2.7.6. Skip to the comment on the latest failure description.

This is what appears to be the real issue: pyenv/pyenv-virtualenv#21

I want to come up with a solution that "just works", preferably without hacking up the tox.ini file. I have a hunch that if we could adjust the circleci build environment configuration so that it doesn't create the virtualenv for us, this would work. We can leave the virtualenv creation to tox?

The problem definition I have so far:

CircleCI uses pyenv and the problem seems to be the virtualenv created by pyenv and tox not playing nice together. Specifying a python version in the circle.yml means circle will create and enable a python virtualenv (really a pyenv virtualenv?) of the specified version in your build environment. Apparently there is a difference between pyenv virtualenv and virtualenv? Some details on that here:

From pyenv/pyenv-virtualenv#21 (comment)

More documentation around this might be a good idea in the future. Specifically, something that says that when you activate a pyenv virtualenv that all the shims for other Python versions aren't available.

A comment on pyenv + tox:

From pyenv/pyenv@17c153b:

NOTE: You can activate multiple versions at the same time, including mulitple versions of Python2 or Python3 simultaneously. This allows for parallel usage of Python2 and Python3, and is required with tools like tox. For example, to set your path to first use your system Python and Python3 (set to 2.7.9 and 3.4.2 in this example), but also have Python 3.3.6, 3.2, and 2.5 available on your PATH, one would first pyenv install the missing versions, then set pyenv global system 3.3.6 3.2 2.5. At this point, one should be able to find the full executable path to each of these using pyenv which, e.g. pyenv which python2.5 (should display $PYENV_ROOT/versions/2.5/bin/python2.5), or pyenv which python3.4 (should display path to system Python3).

http://dtor.com/halfire/2015/01/23/pyenv_tox_can_get_along.html

Here are some folks who may have found a workaround:
coala/coala#653

Possibly related issues:

pyenv/pyenv#34
coala/coala#653
pyenv/pyenv#206
pyenv/pyenv#348

Other links:

• CircleCI's docs on Python: https://circleci.com/docs/language-python