Tox: Allow parallel execution of envs (merge or replace detox?)

[ssbarnea]

This is more of an idea that would simplify parallel execution of tests using tox. Why not merging detox into tox?

I do see several benefits from this:

• better visibility
• simplify project management, they already share the same issue tracker
• easier to deploy
• more trust: detox project has last update from 2015 on pypi making people believe it may be abandonware, also the document page contain outdated links to bitbucket.
• once done, pypi admins can replace detox project with an alias to tox (they already did this for other projects).

As part of the proposed consolidation we can even trigger the parallel option via -P command line option.

[hpk42]

could you look into replacing the usage of eventlet/greenlets with plain threads with detox? That's the main block from my point of view for integrating detox into tox as it would introduce a new maybe not fully stable dependency (not sure what the state of eventlet currently is and if it can be installed everywhere etc.).

[ssbarnea]

@hpk42 Thanks for the quick reply. Glad to hear that you don't have anything against it. I will have a look.

[davidism]

If this happens, I'd also like to be able to mark some envs as "synchronous" so that, for example, coverage collection only happens after all the parallel tests run.

[obestwalter]

I just saw in the README that detox only runs with 2.6 and 2.7 is this still true? This would have to be considered when merging also, depending on what the reason fro this is.

[pawamoy]

Well detox is now tested against 2.7, 3.4, 3.5 and 3.6: https://travis-ci.org/tox-dev/detox, so maybe we could remove the note in detox's README.

[davidism]

I've installed and used it from Python 3 envs without issue.

[obestwalter]

Hi @hpk42,

README says:

detox runs only on python2.6 and python2.7 (but supports creation of python3 and all environments supported of the underlying "tox" command)

is this still valid?

[nirs]

Running multiple processes should be easy without eventlet, just little more code.
Is it ok to depend on concurrent.futures, or we prefer to have no dependencies?

[ssbarnea]

I vote for using dependencies, if they are reliable and maintained, like those that are going to become part of future version of python.

detox works with most versions of python, the info is outdated.

[jfboismenu]

Has anyone started work on this? I’m open to taking a stab at it. I’d love to have everyone at work use only tox and add support for environment dependency management so collection jobs (like collecting coverage from different builds into a single report) could be run after a subset of environments have been executed.

[obestwalter]

Hi @jfboismenu - thanks, have a go. I'd love to have this merged and as far as I know, nobody is working on this.

[ssbarnea]

Yeah, feel free to takeover this. Sadly I am too busy with other bugs to have time to implement this but if you raise a PR, I could help reviewing it. Thanks.

[gaborbernat]

The way I see detox will remain separate. That being said tox can/should get a parallel flag; however the implementation of this would have little to do with the current detox; instead would be an alternative. Will tackle this after having pep-517/8 support and pyproject.toml configuration; as the order of importance.

[obestwalter]

Hi @gaborbernat, what would be different with the parallel flag?

I would really like to see detox vanish into tox core, because as a free standing project it is de facto unmaintained. So when tox grows this parallel functionality I would propose that we mark detox as obsolete and unmaintained. See https://github.com/tox-dev/detox/issues/27

[gaborbernat]

A minimal viable implementation is now available under #1102, anyone interested feel free to review and submit your thoughts.