Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inject TOX_PARALLEL_ENV environment variables #1139

Merged
merged 2 commits into from Jan 15, 2019

Conversation

@adamantike
Copy link
Contributor

@adamantike adamantike commented Jan 14, 2019

To allow other libraries, or projects, to know if Tox is running in
parallel mode, add the TOX_PARALLEL_ENV environment variable to the
list of injected variables.

Particularly, this is useful for pytest-django to know if Tox is
running in parallel mode, to rename test databases [0].

[0] pytest-dev/pytest-django#680

@gaborbernat
Copy link
Member

@gaborbernat gaborbernat commented Jan 15, 2019

My main argument with this is still that why would tox -e py27,py36 -p all work, but tox -e py27 and tox -e py36 from two separate shells in parallel not? I don't believe you need this to solve your problem in general. Otherwise, I'm ok with it.

Copy link
Member

@gaborbernat gaborbernat left a comment

The CI will need fixing.

@adamantike
Copy link
Contributor Author

@adamantike adamantike commented Jan 15, 2019

@gaborbernat I see what you mean. At least for the particular case of pytest-django, I'm trying to adhere to the principle of least surprise in pytest-dev/pytest-django#680, and only rename databases when it's completely required. As a lot of projects use some sort of CI parallelization instead of this feature, they won't need DB renaming, so it could be an unexpected change for them that the generated database is called test_data_py37-django21 instead of test_data.

In a general sense, this PR will only generate a contract for tox, where it must populate the TOX_PARALLEL_ENV variable when it's running in parallel, to provide this info to interested third party projects, which I think could also solve other possible collision issues in some environments.

Regarding the CI errors, I don't see how these changes could have broken them. Based on the logs, I think it's actually failing because of the unicode chars added to the stdout when running in parallel mode:

In windows_py27 job:
UnicodeEncodeError: 'ascii' codec can't encode character u'\u280b' in position 335: ordinal not in range(128)

Can you confirm this is the case?

@gaborbernat
Copy link
Member

@gaborbernat gaborbernat commented Jan 15, 2019

The change broke it. The parallel config has unicode literals, the passenv whitelist should not. Windows breaks on python 2.7 when you put unicode vars into the os.environ.

@adamantike adamantike force-pushed the pass-tox-parallel-env-var branch from 7341426 to fd3c684 Jan 15, 2019
@adamantike
Copy link
Contributor Author

@adamantike adamantike commented Jan 15, 2019

I see, and that's not completely evident because the file where the ENV_VAR_KEY constant is defined uses unicode_literals, but the file that defines the passenv whitelist doesn't. Latest amend should fix the issue.

To allow other libraries, or projects, to know if Tox is running in
parallel mode, add the `TOX_PARALLEL_ENV` environment variable to the
list of injected variables.

Particularly, this is useful for `pytest-django` to know if Tox is
running in parallel mode, to rename test databases [0].

[0] pytest-dev/pytest-django#680
@adamantike adamantike force-pushed the pass-tox-parallel-env-var branch from fd3c684 to 0187833 Jan 15, 2019
@gaborbernat gaborbernat merged commit 42ecc92 into tox-dev:master Jan 15, 2019
5 checks passed
@gaborbernat
Copy link
Member

@gaborbernat gaborbernat commented Jan 15, 2019

Thanks!

@adamantike adamantike deleted the pass-tox-parallel-env-var branch Jan 15, 2019
gaborbernat added a commit to gaborbernat/tox that referenced this issue Jan 20, 2019
* Inject TOX_PARALLEL_ENV environment variables

To allow other libraries, or projects, to know if Tox is running in
parallel mode, add the `TOX_PARALLEL_ENV` environment variable to the
list of injected variables.

Particularly, this is useful for `pytest-django` to know if Tox is
running in parallel mode, to rename test databases [0].

[0] pytest-dev/pytest-django#680

* Use strings (bytestrings in Python 2) in passenv whitelist
@hroncok
Copy link
Contributor

@hroncok hroncok commented Oct 21, 2019

See also #1444

hroncok added a commit to hroncok/tox that referenced this issue Oct 21, 2019
...but keep the TOX_PARALLEL_ENV variable for others to consume.

The problem with using environment variables to let tox know it's being run
as a parallel worker is the following:

Either you don't pass the environment variable, but the test frameworks and
test suites are unaware that tox is running in parallel.
This makes it hard for cases like pytest-django:
tox-dev#1139

Or you pass the environment variable, but it makes tox invoked within tox
think it is a parallel worker even when it isn't.
This makes it hard to test various tox plugins that invoke tox in their
integration test suite:
Fixes tox-dev#1444

By introducing two variables we can use one ("private", _TOX_PARALLEL_ENV) to
control the behavior of tox (and don't pass it) and another ("public",
TOX_PARALLEL_ENV) to let the tests and test frameworks know tox is running
in parallel (and pass it by default).
hroncok added a commit to hroncok/tox that referenced this issue Oct 21, 2019
...but keep the TOX_PARALLEL_ENV variable for others to consume.

The problem with using environment variables to let tox know it's being run
as a parallel worker is the following:

Either you don't pass the environment variable, but the test frameworks and
test suites are unaware that tox is running in parallel.
This makes it hard for cases like pytest-django:
tox-dev#1139

Or you pass the environment variable, but it makes tox invoked within tox
think it is a parallel worker even when it isn't.
This makes it hard to test various tox plugins that invoke tox in their
integration test suite:
Fixes tox-dev#1444

By introducing two variables we can use one ("private", _TOX_PARALLEL_ENV) to
control the behavior of tox (and don't pass it) and another ("public",
TOX_PARALLEL_ENV) to let the tests and test frameworks know tox is running
in parallel (and pass it by default).
hroncok added a commit to hroncok/tox that referenced this issue Oct 22, 2019
...but keep the TOX_PARALLEL_ENV variable for others to consume.

The problem with using environment variables to let tox know it's being run
as a parallel worker is the following:

Either you don't pass the environment variable, but the test frameworks and
test suites are unaware that tox is running in parallel.
This makes it hard for cases like pytest-django:
tox-dev#1139

Or you pass the environment variable, but it makes tox invoked within tox
think it is a parallel worker even when it isn't.
This makes it hard to test various tox plugins that invoke tox in their
integration test suite:
Fixes tox-dev#1444

By introducing two variables we can use one ("private", _TOX_PARALLEL_ENV) to
control the behavior of tox (and don't pass it) and another ("public",
TOX_PARALLEL_ENV) to let the tests and test frameworks know tox is running
in parallel (and pass it by default).
hroncok added a commit to hroncok/tox that referenced this issue Oct 22, 2019
...but keep the TOX_PARALLEL_ENV variable for others to consume.

The problem with using environment variables to let tox know it's being run
as a parallel worker is the following:

Either you don't pass the environment variable, but the test frameworks and
test suites are unaware that tox is running in parallel.
This makes it hard for cases like pytest-django:
tox-dev#1139

Or you pass the environment variable, but it makes tox invoked within tox
think it is a parallel worker even when it isn't.
This makes it hard to test various tox plugins that invoke tox in their
integration test suite:
Fixes tox-dev#1444

By introducing two variables we can use one ("private", _TOX_PARALLEL_ENV) to
control the behavior of tox (and don't pass it) and another ("public",
TOX_PARALLEL_ENV) to let the tests and test frameworks know tox is running
in parallel (and pass it by default).
hroncok added a commit to hroncok/tox that referenced this issue Oct 22, 2019
...but keep the TOX_PARALLEL_ENV variable for others to consume.

The problem with using environment variables to let tox know it's being run
as a parallel worker is the following:

Either you don't pass the environment variable, but the test frameworks and
test suites are unaware that tox is running in parallel.
This makes it hard for cases like pytest-django:
tox-dev#1139

Or you pass the environment variable, but it makes tox invoked within tox
think it is a parallel worker even when it isn't.
This makes it hard to test various tox plugins that invoke tox in their
integration test suite:
Fixes tox-dev#1444

By introducing two variables we can use one ("private", _TOX_PARALLEL_ENV) to
control the behavior of tox (and don't pass it) and another ("public",
TOX_PARALLEL_ENV) to let the tests and test frameworks know tox is running
in parallel (and pass it by default).
hroncok added a commit to hroncok/tox that referenced this issue Oct 22, 2019
...but keep the TOX_PARALLEL_ENV variable for others to consume.

The problem with using environment variables to let tox know it's being run
as a parallel worker is the following:

Either you don't pass the environment variable, but the test frameworks and
test suites are unaware that tox is running in parallel.
This makes it hard for cases like pytest-django:
tox-dev#1139

Or you pass the environment variable, but it makes tox invoked within tox
think it is a parallel worker even when it isn't.
This makes it hard to test various tox plugins that invoke tox in their
integration test suite:
Fixes tox-dev#1444

By introducing two variables we can use one ("private", _TOX_PARALLEL_ENV) to
control the behavior of tox (and don't pass it) and another ("public",
TOX_PARALLEL_ENV) to let the tests and test frameworks know tox is running
in parallel (and pass it by default).
hroncok added a commit to hroncok/tox that referenced this issue Oct 22, 2019
...but keep the TOX_PARALLEL_ENV variable for others to consume.

The problem with using environment variables to let tox know it's being run
as a parallel worker is the following:

Either you don't pass the environment variable, but the test frameworks and
test suites are unaware that tox is running in parallel.
This makes it hard for cases like pytest-django:
tox-dev#1139

Or you pass the environment variable, but it makes tox invoked within tox
think it is a parallel worker even when it isn't.
This makes it hard to test various tox plugins that invoke tox in their
integration test suite:
Fixes tox-dev#1444

By introducing two variables we can use one ("private", _TOX_PARALLEL_ENV) to
control the behavior of tox (and don't pass it) and another ("public",
TOX_PARALLEL_ENV) to let the tests and test frameworks know tox is running
in parallel (and pass it by default).
hroncok added a commit to hroncok/tox that referenced this issue Oct 22, 2019
...but keep the TOX_PARALLEL_ENV variable for others to consume.

The problem with using environment variables to let tox know it's being run
as a parallel worker is the following:

Either you don't pass the environment variable, but the test frameworks and
test suites are unaware that tox is running in parallel.
This makes it hard for cases like pytest-django:
tox-dev#1139

Or you pass the environment variable, but it makes tox invoked within tox
think it is a parallel worker even when it isn't.
This makes it hard to test various tox plugins that invoke tox in their
integration test suite:
Fixes tox-dev#1444

By introducing two variables we can use one ("private", _TOX_PARALLEL_ENV) to
control the behavior of tox (and don't pass it) and another ("public",
TOX_PARALLEL_ENV) to let the tests and test frameworks know tox is running
in parallel (and pass it by default).

The integration test is a tad complicated invoking subprocess.Popen instead
of subprocess.run, to support Python 2.7 and 3.4.
hroncok added a commit to hroncok/tox that referenced this issue Oct 23, 2019
...but keep the TOX_PARALLEL_ENV variable for others to consume.

The problem with using environment variables to let tox know it's being run
as a parallel worker is the following:

Either you don't pass the environment variable, but the test frameworks and
test suites are unaware that tox is running in parallel.
This makes it hard for cases like pytest-django:
tox-dev#1139

Or you pass the environment variable, but it makes tox invoked within tox
think it is a parallel worker even when it isn't.
This makes it hard to test various tox plugins that invoke tox in their
integration test suite:
Fixes tox-dev#1444

By introducing two variables we can use one ("private", _TOX_PARALLEL_ENV) to
control the behavior of tox (and don't pass it) and another ("public",
TOX_PARALLEL_ENV) to let the tests and test frameworks know tox is running
in parallel (and pass it by default).

The integration test is a tad complicated invoking subprocess.Popen instead
of subprocess.run, to support Python 2.7 and 3.4.
hroncok added a commit to hroncok/tox that referenced this issue Oct 23, 2019
...but keep the TOX_PARALLEL_ENV variable for others to consume.

The problem with using environment variables to let tox know it's being run
as a parallel worker is the following:

Either you don't pass the environment variable, but the test frameworks and
test suites are unaware that tox is running in parallel.
This makes it hard for cases like pytest-django:
tox-dev#1139

Or you pass the environment variable, but it makes tox invoked within tox
think it is a parallel worker even when it isn't.
This makes it hard to test various tox plugins that invoke tox in their
integration test suite:
Fixes tox-dev#1444

By introducing two variables we can use one ("private", _TOX_PARALLEL_ENV) to
control the behavior of tox (and don't pass it) and another ("public",
TOX_PARALLEL_ENV) to let the tests and test frameworks know tox is running
in parallel (and pass it by default).

The integration test is a tad complicated invoking subprocess.Popen instead
of subprocess.run, to support Python 2.7 and 3.4.
hroncok added a commit to hroncok/tox that referenced this issue Oct 23, 2019
...but keep the TOX_PARALLEL_ENV variable for others to consume.

The problem with using environment variables to let tox know it's being run
as a parallel worker is the following:

Either you don't pass the environment variable, but the test frameworks and
test suites are unaware that tox is running in parallel.
This makes it hard for cases like pytest-django:
tox-dev#1139

Or you pass the environment variable, but it makes tox invoked within tox
think it is a parallel worker even when it isn't.
This makes it hard to test various tox plugins that invoke tox in their
integration test suite:
Fixes tox-dev#1444

By introducing two variables we can use one ("private", _TOX_PARALLEL_ENV) to
control the behavior of tox (and don't pass it) and another ("public",
TOX_PARALLEL_ENV) to let the tests and test frameworks know tox is running
in parallel (and pass it by default).

The integration test is a tad complicated invoking subprocess.Popen instead
of subprocess.run, to support Python 2.7 and 3.4.
hroncok added a commit to hroncok/tox that referenced this issue Oct 23, 2019
...but keep the TOX_PARALLEL_ENV variable for others to consume.

The problem with using environment variables to let tox know it's being run
as a parallel worker is the following:

Either you don't pass the environment variable, but the test frameworks and
test suites are unaware that tox is running in parallel.
This makes it hard for cases like pytest-django:
tox-dev#1139

Or you pass the environment variable, but it makes tox invoked within tox
think it is a parallel worker even when it isn't.
This makes it hard to test various tox plugins that invoke tox in their
integration test suite:
Fixes tox-dev#1444

By introducing two variables we can use one ("private", _TOX_PARALLEL_ENV) to
control the behavior of tox (and don't pass it) and another ("public",
TOX_PARALLEL_ENV) to let the tests and test frameworks know tox is running
in parallel (and pass it by default).

The integration test is a tad complicated invoking subprocess.Popen instead
of subprocess.run, to support Python 2.7 and 3.4.
gaborbernat added a commit that referenced this issue Nov 11, 2019
...but keep the TOX_PARALLEL_ENV variable for others to consume.

The problem with using environment variables to let tox know it's being run
as a parallel worker is the following:

Either you don't pass the environment variable, but the test frameworks and
test suites are unaware that tox is running in parallel.
This makes it hard for cases like pytest-django:
#1139

Or you pass the environment variable, but it makes tox invoked within tox
think it is a parallel worker even when it isn't.
This makes it hard to test various tox plugins that invoke tox in their
integration test suite:
Fixes #1444

By introducing two variables we can use one ("private", _TOX_PARALLEL_ENV) to
control the behavior of tox (and don't pass it) and another ("public",
TOX_PARALLEL_ENV) to let the tests and test frameworks know tox is running
in parallel (and pass it by default).

The integration test is a tad complicated invoking subprocess.Popen instead
of subprocess.run, to support Python 2.7 and 3.4.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

4 participants