[TIP] tox "empty" factors for generated environment?

[holger krekel]

Hi Barry, 

CCing Alexander Schepanovski, who helped to conceive and implement factors
and might feel like commenting.  IIRC I disucssed with him about negation
(what i suggest below) and saw some problems but it seems now to me that the
below suggestion is workable.

On Wed, Jan 27, 2016 at 13:53 -0500, Barry Warsaw wrote:
> tox's generated environments are very cool.  A question that sometimes comes
> up is whether it's possible to include "empty" factors.  Hopefully this makes
> sense.
> 
> Let's say I want to define the following environments: py27 and py35 both for
> the defaults and a coverage version.  I could do something like:
> 
> [testenv:py27]
> ...
> [testenv:py35]
> ...
> [testenv:py27-coverage]
> ...
> [testenv:py35-coverage]
> ...
> 
> I'd like to be able to use generated environments, e.g.
> 
> envlist = {py27,py35}{,-coverage}
> 
> but I don't think that's possible.
> 
> In that form it might not make sense because you'd have to define "" and
> "-coverage" lines before the colon.
> 
> My current solution is to do something like:
> 
> envlist = {py27,py35}-{nocov,cov}
> 
> and then use the normal generated environments syntax.  But I don't like
> having to say something like `tox -e py35-nocov` when I want to run just that
> environment.
> 
> Is there any way in which empty/default factors could be defined?

Not sure.  I guess we could think again about negation, i.e. that

    coverage: ...
    !coverage: ...

so that "!coverage" means "is not an existing factor in the env".
One should be able to use it also like this with negation being more
eager than the "-" which signifies "AND":

    !coverage-!py27: # both coverage and py27 are not part of envname

    !coverage-py27: # coverage not part, py27 is part of envname

And btw ordering is irrelevant:

    !py27-!coverage: # both coverage and py27 are not part of envname

    py27-!coverage: # coverage not part and py27 is part of envname

The "," is used as "OR" and "!" would bind more eager than it as well.

Would this be helpful in your case?
do you think it's a good new unambigous syntax?

holger