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.

Sign up for GitHub

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

Jump to bottom

Inject TOX_PARALLEL_ENV environment variables #1139

Merged
merged 2 commits into from
Jan 15, 2019
Merged

Inject TOX_PARALLEL_ENV environment variables #1139

merged 2 commits into from
Jan 15, 2019

Conversation

adamantike
Copy link

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 mentioned this pull request Jan 14, 2019
Merged
@gaborbernat
Copy link
Member

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.

gaborbernat
gaborbernat requested changes Jan 15, 2019
View reviewed changes
Copy link
Member

@gaborbernat gaborbernat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The CI will need fixing.

@adamantike
Copy link
Author

@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 commented Jan 15, 2019 •
edited
Loading

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
Copy link
Author

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.

@adamantike
Inject TOX_PARALLEL_ENV environment variables
0187833 
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 gaborbernat merged commit 42ecc92 into tox-dev:master Jan 15, 2019
@gaborbernat
Copy link
Member

Thanks!

@adamantike adamantike deleted the pass-tox-parallel-env-var branch January 15, 2019 12:36
gaborbernat pushed a commit to gaborbernat/tox that referenced this pull request Jan 20, 2019
@adamantike @gaborbernat
Inject TOX_PARALLEL_ENV environment variables (tox-dev#1139)
d6cd8d4 
* 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 hroncok mentioned this pull request Oct 21, 2019
Closed
@hroncok
Copy link
Contributor

hroncok commented Oct 21, 2019

See also #1444

hroncok added a commit to hroncok/tox that referenced this pull request Oct 21, 2019
@hroncok
Use _TOX_PARALLEL_ENV environment variable to control the behavior
9934a34 
...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 pull request Oct 21, 2019
@hroncok
Use _TOX_PARALLEL_ENV environment variable to control the behavior
23651c5 
...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 hroncok mentioned this pull request Oct 21, 2019
Merged
6 tasks
hroncok added a commit to hroncok/tox that referenced this pull request Oct 22, 2019
@hroncok
Use _TOX_PARALLEL_ENV environment variable to control the behavior
4cb6d03 
...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 pull request Oct 22, 2019
@hroncok
Use _TOX_PARALLEL_ENV environment variable to control the behavior
3fbb982 
...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 pull request Oct 22, 2019
@hroncok
Use _TOX_PARALLEL_ENV environment variable to control the behavior
4a9341e 
...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 pull request Oct 22, 2019
@hroncok
Use _TOX_PARALLEL_ENV environment variable to control the behavior
2801d45 
...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 pull request Oct 22, 2019
@hroncok
Use _TOX_PARALLEL_ENV environment variable to control the behavior
bd42985 
...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 pull request Oct 22, 2019
@hroncok
Use _TOX_PARALLEL_ENV environment variable to control the behavior
246e752 
...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 pull request Oct 23, 2019
@hroncok
Use _TOX_PARALLEL_ENV environment variable to control the behavior
1e75d24 
...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 pull request Oct 23, 2019
@hroncok
Use _TOX_PARALLEL_ENV environment variable to control the behavior
322d066 
...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 pull request Oct 23, 2019
@hroncok
Use _TOX_PARALLEL_ENV environment variable to control the behavior
a225a18 
...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 pull request Oct 23, 2019
@hroncok
Use _TOX_PARALLEL_ENV environment variable to control the behavior
d646262 
...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 pushed a commit that referenced this pull request Nov 11, 2019
@hroncok @gaborbernat
Use _TOX_PARALLEL_ENV environment variable to control the behav… (#1446)
0a44dcc 
...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
Reviewers

@obestwalter obestwalter obestwalter left review comments

@gaborbernat gaborbernat gaborbernat requested changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
4 participants
@adamantike @gaborbernat @hroncok @obestwalter