enable use of tox grouping or aliases for running multiple environments

[ssbarnea]

As a tox user, if I want to run all linting targets on a project I can easily up with a command that looks like tox -e yamllint,flake8,ansible-lint,ansible-check,ansible-syntax-check real life scenario

It I could tell tox that lint=yamllint,flake8,ansible-lint,ansible-check,ansible-syntax-check, I could easily run it with just tox -e lint

I seen people using Makefiles to simplify triggering differing tox targets but I think we should improve tox itself so we would not have to require people to use wrappers to hide that ugly complexity.

[warsaw]

This is related to #238 and #427 and would solve my requests in #223 and #418

It's probably my top wishlist for tox!

[asottile]

I like this idea, I'll try and hack on something like this this weekend -- maybe first as a plugin and work out the interface before merging into tox itself.

[gaborbernat]

This needs some thought, as aliases also need to have a description, and can easily see the need to have them special args for them. Maybe this warrants a new section in tox config, or maybe we can have umbrella environments that hide multiple envs underneath; and we'll also need to figure out what happens when tox -e lint,py27 is invoked e.g.

[ssbarnea]

When consider a solution we should also look at #646 which asks for a way to avoid unknown environment parameters. They seem to be around the same area.

[TheLarsinator]

What I would like is something like:
envlist = {py34,py35,py36,py37}-{A, B, C}

and then run tox with:

tox -e *-A: Run A for all python versions
tox -e py36-*: Run A, B and C for python 36 

And perhaps even:
tox -e *-A,*-B: Run A and B for all python versions

[obestwalter]

I just added the "hard" label here, because I think there are several factors that would make something like this hard:

1. The organically grown parsing/factoring/substitution logic is not clearly specified and the code is not easy to understand. Changing/extending that logic tends to yield surprising interaction and side effects. There also seem to be gaps in our testing, which leads to these things usually rearing their ugly heads after a release.
2. There are a lot of ideas and wishes coming together here that need to be discussed and agreed upon first
3. There are also a considerable amount of open bugs regarding configuration, which I feel would better be be looked at and fixed before adding new features like this
4. Then there is also the thought we are throwing around to completely feature freeze the existing tox.ini format and only accept bug fixes for it. New features would then only be available in the tool.tox part of pyproject.toml, which we need to support as a consumer anyway (PEP-518 wheel support #850) and also plan to support as a provider (Allow configuration via tool.tox in pyproject.toml #814) ... or whatever terminology one should use for that kind of thing. If we stick with this decision and make it official, PRs regarding new features in the old format would likely not be accepted anymore ... unless they have a level of quality and testing that would make it very hard to say no to.

[gaborbernat]

I think for now we can say that grouping/aliasing is a won't fix; or at least deferred to the new pyproject.toml format. That being said a low hanging fruit that will get most people what they want is to add the ability of fnmatch selection of envs with positive and negative matching.

py* - run all from default envs that start with py
!py* - run all from default envs that don't star with py

[obestwalter]

Closing this as wontfix then referring to the NewHope(TM) coming up in #999.

[obestwalter]

(oops better make this consistent and keep open until things are clarified in #999)

[gaborbernat]

A labeling system has been added with #2290