[TIP] Tox command line substitutions

Chris Rose offline at offby1.net
Fri Jan 7 06:41:40 PST 2011

I'd just like to make sure I'm clear on the approach here (forgive my

1. retain support for the bare '[]' syntax, as a deprecated method for
specifying the positional arguments
2. add a new syntax for positional arguments like so:


DEFAULT may itself be a series of interpreted strings, of course,
which might resolve into environment variables and so on.

I'd like to propose one further amendment: Change from {} as a
substitution marker to {{}} (a al django templates, for example)
because I can think of at least one command pattern that's pretty
common (find ... -exec ... {} \;) that will trigger this.

I'd call that a secondary concern, though. Getting the positional
argument syntax to be correct would be more important.

On Fri, Jan 7, 2011 at 7:32 AM, holger krekel <holger at merlinux.eu> wrote:
> Hi Chris,
> just back from vacation - you also filed issue15 IISIC.
> (And i'd like to cross-post this mail to the issue but ASFAIK unfortunately
> GCode does not allow updating an issue by mail ...)
> http://code.google.com/p/pytox/issues/detail?id=15
> More inline commenting ...
> On Wed, Jan 05, 2011 at 08:48 -0700, Chris Rose wrote:
>> I ran into an issue with tox command positional argument substitution
>> that I was going to look into fixing, but it turns out that at least
>> to some extent the issue is by design (at least, according to the unit
>> tests in tox).
>> Here's my own example, with expected behaviour:
>> command = nosetests -m '(?:^|[\\b_\\./-])(?:unit)?[Tt]est'
>> Tox substitutes this as:
>> nosetests -m '(?:^|POSARGS)(?:unit)?POSARGSest'
>> Obviously, this is undesirable.
>> >From the unit tests, I see that by design tox is expected to support
>> replacing multi-word elements in the command as denoted by []
>> characters with the positional arguments, if provided, and if not, to
>> strip them out completely:
>>            [section]
>>            key2=
>>                cmd1 []
>>                cmd2 [{item2} \
>>                     other]
>> Here, cmd2 will either be "cmd2 POSARGS", "cmd2", or "cmd2 item2value"
>> depending on substitutions
>> So, the question is, then, is this a good design for command
>> substitution? \[.*\] is a VERY greedy way to replace text in a
>> command, especially given that there's no way to escape these strings
>> as it stands. Also, any escaping scheme is going to be subject to some
>> potentially awful nested escaping issues, depending on how the command
>> is executed. That might not be a problem -- I suspect that the command
>> is executed using subprocess, so shell escaping is moot -- but it
>> might be a hard problem to solve.
>> For my part, I'd suggest changing the substitution marker to something
>> less likely to ever be found in a command line; '{{}}' or '<<<>>>' or
>> something like it, or to add a way to escape them.
> To keep things mostly compatible i like your suggestion to
> (continue to) recognize "[]" literally and disallow specifying
> default arguments.  We should this via a a {*} substitution
> and phase out "[]" usage in the documentation and examples.
> This way we end upw ith only one substitution mechanism
> which makes it easier to think about escaping/providing
> default values etc.
>> I'd like to contribute a fix to this, but first I need to know what
>> the right fix should be. Thoughts?
> if the above makes sense i'd be happy to review and merge your fix.
> cheers,
> holger
>> --
>> Chris R.
>> ======
>> Not to be taken literally, internally, or seriously.
>> Twitter: http://twitter.com/offby1
>> _______________________________________________
>> testing-in-python mailing list
>> testing-in-python at lists.idyll.org
>> http://lists.idyll.org/listinfo/testing-in-python
> --

Chris R.
Not to be taken literally, internally, or seriously.
Twitter: http://twitter.com/offby1

More information about the testing-in-python mailing list