This is working at intended. tox is about reproducible build, hard coding to full path seems from this point wrong as it's almost bound to fail on other peoples system. Discovery on Linux systems should be via having the pythonx.y format as specifiad in tox follows this logic for interpreter discovery, especially for pre-defined build environments. 

That being said I know this worked until now. So in that sense it's a regression. I would say though that your use case is the edge case, if you want to use it like that define custom tox environments, e.g. py27k instead of py27. In general, for people who follow the python discovery system enlisted in that pep, this change should help them avoid invalid configuration and bad suprises.

On Jul 13, 2018 10:55, "Oliver Bestwalter" <> wrote:
Hi Fred,

this is a fix introduced new in 3.1 to make sure that the wrong interpreter isn't used silently when tox is misconfigured. I wasn't involved in the fix and lack the details, but your config looks like there should be no such warning. When you say that py36 and py37 weren't found at all: do you mean that the warning shadows an actual error? If this is the case, it would be great if you could open an issue with a quick explanation how to reproduce this.

Here are the details for this issue and the changes, if you want to look further into this:


On Thu, 12 Jul 2018 at 16:39 Fred Drake <> wrote:
On Thu, Jul 12, 2018 at 10:23 AM Fred Drake <> wrote:
> I see the docs for the setting "ignore_basepython_conflict", and would
> like to understand how tox is intended to be configured for alternate
> Python installations like mine.

Playing further with it, setting "ignore_basepython_conflict = true"
causes my setting of the value to be ignored, so the Python
interpreter for py36 and py37 aren't found at all.


Fred L. Drake, Jr.    <fred at>
"A storm broke loose in my mind."  --Albert Einstein
tox-dev mailing list --
To unsubscribe send an email to
tox-dev mailing list --
To unsubscribe send an email to