Its too radical. I'm working on improvements and I think lots of envs are acceptable but only on when run cron.
xdist: I still want it. You could disable it but leave ability to enable it by individuals.

1. The PR fixes the real flakiness, so it is useful.
2. It reduces execution time even more than xdist appliance.
3. A set of tested environments is always a compromise between tests execution time and amount of scenarios to test. Personally, I have a feeling that testing on uvloop is redundant.

That's why I'd like to keep the PR merged.
When you''ll find a time for improvements -- let's discuss it.

Sure, I'm not implying unmerging it. It's just the way it's solved is a bit conflicting with my ideas. We still need tox-based envs in place when I get to it...

I feel uncomfortable with tox when working on daily tasks:

1. I don't need to reactivate environment between test runs, the current activated virtual env works pretty fine.
2. No need to run multiple test passes locally and wait for the long run. Passing tests in the current venv is a good sign for pushing a PR on github, CI will do the rest checks.

@webknjaz pytest-xdist problem can be solved by introducing xdist_run_in_main_thread marker probably, but I have no time to contribute into the plugin, sorry.
I hope you understand my position.
Now the feature doesn't exist.

@asvetlov

1. It looks like you miss the point: I suspect you're using it wrong. You don't have to reactivate the env and maybe you just need to get familiar with how it works. Could you please make an https://asciinema.org/ recording of what's going wrong?

2. This is not my default setup either: in my configurations tox always uses currently available Python. So your assumption is wrong.

3. The idea about the marker is interesting, I'll need to think about it. But again, I want to keep the plugin even turned off so that it won't affect anyone.

4. I'm trying to get rid of that spaghetti mess currently present in Makefile: it's harmful and not CI-agnostic. I want to have a place with envs described independently from CIs or any other external (local/dev) envs so that it'd be clean.

This thread has been automatically locked since there has not been
any recent activity after it was closed. Please open a new issue for
related bugs.

If you feel like there's important points made in this discussion,
please include those exceprts into that new issue.