Description
I don't know if this is worth tackling, as this is an edge case that should only realistically affect plugin authors. In short, the TOX_PARALLEL_ENV is always added to the passenv, which is then propagated to the downstream tox/python subprocesses. Normally, this shouldn't matter, since most tox users won't care about the env var. However, this affects test cases that in turn invoke tox itself (i.e., integration tests for plugins like tox-factor and tox-travis). I think this issue should also mean that you can't run tox's test suite in parallel.
As an example, take a potential integration test. It would setup a fake project with a tox config, then run some tox test command. The process tree would look something like:
tox
└ python test command
└ tox test command
However, if we run this test suite in parallel, the internal tox invocation will already have TOX_PARALLEL_ENV set, which is propagated to the various subprocesses, affecting the internal tox test. e.g., it looks something like this:
tox --parallel auto
└ TOX_PARALLEL_ENV=py37 tox
└ TOX_PARALLEL_ENV=py37 python test command
└ TOX_PARALLEL_ENV=py37 tox test command
Instead of running normally, the nested tox test command thinks it's running as a parallelized subprocess. I think this can be fixed by having the parallelized tox subprocess remove the TOX_PARALLEL_ENV from either its environment variables, or from its subprocess's environment variables.
My current workaround is to modify the subprocess environ in my own code. e.g., my plugin tests invoke tox like so:
def _tox_call(self, arguments):
env = os.environ.copy()
env.pop(TOX_PARALLEL_ENV, None)
proc = subprocess.Popen(
arguments, stdout=subprocess.PIPE, stderr=subprocess.PIPE, env=env)
stdout, stderr = proc.communicate()
return proc.returncode, stdout.decode('utf-8'), stderr.decode('utf-8')