posargs fails when providing arguments with spaces in quotes

[pytoxbot]

• Bitbucket: https://bitbucket.org/hpk42/tox/issue/310
• Originally reported by: @sigmavirus24
• Originally created at: 2016-02-07T17:22:46.479

An example tox.ini

[testenv:venv]
deps =
    flake8
commands = flake8 {posargs}

And the usage

$ tox -e venv -- --format="%(code)s:%(path)s:%(row)s:%(col)s: %(text)s"
$ tox -e venv -- --format='%(code)s:%(path)s:%(row)s:%(col)s: %(text)s'

In both cases %(text)s is not passed as part of the argument to --format but instead is passed as an argument as if the user did instead

$ tox -e venv -- --format="%(code)s:%(path)s:%(row)s:%(col)s:" "%(text)s"

No amount of escaping (either of the space or the quotes) works. What does work, however, is:

$ tox -e venv -- --format="'%(code)s:%(path)s:%(row)s:%(col)s: %(text)s'"

In other words, using both types of quotes works.

I looked but didn't see this reported anywhere else and I'm frankly not certain this is something that can be fixed.

[pytoxbot]

Original comment by nitrocode

I agree too. I spent well more than 30 minutes debugging this and fixing it.

I'm now running a patched version of tox in order to use the spaces... I wish I saw this thread before doing all that work.

See #340 for the patch.

[pytoxbot]

Original comment by nitrocode

Issue #340 was marked as a duplicate of this issue.

[pytoxbot]

Original comment by @blueyed

I totally agree, and mentioned even the same xkcd comic in this context.. :)

[pytoxbot]

Original comment by @sigmavirus24

@blueyed yeah the typical workflow dilemma. Anyway, I described that hack around it above and have been just avoiding it by not using tox + posargs when necessary. I think that points to it needing to be fixed because I don't care to have to do the extra work to make tox do the right thing.

I'm leaving the issue open anyway. At the very least tox should document this as a known quantity so others don't have to spend 30 minutes experimenting/debugging to find the right way to make this work.

[pytoxbot]

Original comment by @blueyed

You can use tox -e py35 -- -k "'foo or bar'" -s, i.e. put an additional level of quotes around it.

It will still say the following (without quotes) though, but work:

py35 runtests: commands[0] | py.test --lsof -rfsxX -k foo or bar -s

(According to @The-Compiler it might not get fixed, because people might be used to this workaround already?!)

[pytoxbot]

Original comment by glouie

I have similar problems as well and would like to know how to pass arguments with spaces or even able to pass in single or double quotes

I"m trying to run tox and pass arguments down to py.test.

#!


[testenv:pytest]
deps = 
    pytest
commands = py.test {posargs}

Usage:

#!

$ tox -e pytest -- -k "foo bar" 

instead of running

#!

$ py.test -k "foo bar" 

it runs

#!

$ pytest -k foo bar

[jaraco]

As I'm transitioning my projects from pytest-runner to tox, I encountered this issue today:

$ cat tox.ini
[tox]
skipsdist = True

[testenv]
commands =
    python -c "import sys; print(sys.argv)" {posargs}
$ python -m tox -- "foo bar"
python installed: 
python runtests: PYTHONHASHSEED='4003872517'
python runtests: commands[0] | python -c import sys; print(sys.argv) foo bar
['-c', 'foo', 'bar']
___________________________________________ summary ____________________________________________
  python: commands succeeded
  congratulations :)

I verified that the proposed workaround does work.

$ python -m tox -- "'foo bar'"
python installed: 
python runtests: PYTHONHASHSEED='3362447837'
python runtests: commands[0] | python -c import sys; print(sys.argv) foo bar
['-c', 'foo bar']
___________________________________________ summary ____________________________________________
  python: commands succeeded
  congratulations :)

it might not get fixed, because people might be used to this workaround already

ugh. That's not right. I'd really like to see a proper fix for this issue... and if absolutely necessary, include an option to retain the broken behavior for those who really must rely on it.

[hpk42]

I agree it's not a good situation and we should see to fix it. I am not sure if we have to care very much wrt to backward-compat but it's probably nice if we do.

[hpk42]

I've created a fix for this issue, please review #385

I am not sure how much of a backward-incompatibility this really is. We could do a tox-2.5 to indicate to people that they should pay a bit more attention instead of just a "micro" 2.4.2 release. What do you think?

My current view is that this only changes how you invoke tox on the command line and relatively few people will have gotten to the work around (double-quoting) and rely on it from automated scripts. Agree, disagree?

[jaraco]

I agree that relatively few will have gotten around to using the workaround in a formal way. I've adopted that technique in just two of our Jenkins scripts, which non-interactively invoke tox -- --junit-xml="'test results.xml'", but I'm pretty sure I can develop a solution that works on new and old versions of tox by passing those parameters in config sections and not in a script. I'm okay with considering the workaround an unsupported hack and thus not strictly backward incompatible.

[jaraco]

I did figure out that I could indeed rely on tox.ini for passing the junitxml:

[tox:jenkins]
envlist = py{34,35,27}-jenkins

[testenv]
usedevelop = True
deps = -rtests/requirements.txt
commands =
    pytest {posargs} {env:JUNITXML:}
setenv =
    PIP_INDEX_URL=https://devpi.yougov.net/root/yg/+simple/
    py{27,34,35}-jenkins: JUNITXML=--junitxml="test results.xml"

[testenv:py27]
commands =
    pip install -e .[parser]
    pytest {posargs} {env:JUNITXML:}

[obestwalter]

fixed in 53f6149