New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UsageError raised when specifying config override options followed by test path(s) #3103

Closed
davehunt opened this Issue Jan 10, 2018 · 8 comments

Comments

Projects
None yet
5 participants
@davehunt
Contributor

davehunt commented Jan 10, 2018

Summary

When using -o or --override-ini followed by one or more test paths, the session terminates with "ERROR: -o/--override-ini expects option=value style."

pipenv graph

pytest==3.3.2
  - attrs [required: >=17.2.0, installed: 17.4.0]
  - pluggy [required: <0.7,>=0.5, installed: 0.6.0]
  - py [required: >=1.5.0, installed: 1.5.2]
  - setuptools [required: Any, installed: 38.2.5]
  - six [required: >=1.10.0, installed: 1.11.0]

Operating System:

macOS High Sierra 10.13.2

Example:

$ pytest -o console_output_style=classic test.py
ERROR: -o/--override-ini expects option=value style.

The relevant code is below. I would suggest that we only raise the exception if the first value does not contain an '=', and stop considering values as overrides as soon as they no longer contain the character.

pytest/_pytest/config.py

Lines 1188 to 1202 in cf9b31b

def _get_override_ini_value(self, name):
value = None
# override_ini is a list of list, to support both -o foo1=bar1 foo2=bar2 and
# and -o foo1=bar1 -o foo2=bar2 options
# always use the last item if multiple value set for same ini-name,
# e.g. -o foo=bar1 -o foo=bar2 will set foo to bar2
for ini_config_list in self._override_ini:
for ini_config in ini_config_list:
try:
(key, user_ini_value) = ini_config.split("=", 1)
except ValueError:
raise UsageError("-o/--override-ini expects option=value style.")
if key == name:
value = user_ini_value
return value

@pytestbot

This comment has been minimized.

pytestbot commented Jan 10, 2018

GitMate.io thinks the contributor most likely able to help you is @nicoddemus.

@pytestbot pytestbot added the type: bug label Jan 10, 2018

@nicoddemus

This comment has been minimized.

Member

nicoddemus commented Jan 10, 2018

. I would suggest that we only raise the exception if the first value does not contain an '=', and stop considering values as overrides as soon as they no longer contain the character.

Sounds reasonable, thanks @davehunt!

@arcoyle

This comment has been minimized.

arcoyle commented Jan 14, 2018

Hi @davehunt, @nicoddemus
I can take a look at this if there is no work already underway?
I am a first time contributor

@nicoddemus

This comment has been minimized.

Member

nicoddemus commented Jan 14, 2018

@arcoyle thanks, we appreciate! Please go ahead! 😁

If you get stuck, feel free to open a PR anyway so we can help out over the code you managed to do so far.

@arcoyle

This comment has been minimized.

arcoyle commented Jan 20, 2018

@nicoddemus I have opened a PR for this issue, could you please review.

One thing I noticed while testing was the use of switch options before the test path stops the exception. Nothing is added to the list of key value pairs after the switch option.
For example if I take out the fix and run the test with a -o console_output_style=classic -s test.py it won't raise the exception.
This is because of how the argparse module behaves. Just thought it would be interesting to note as it could cause some tests to mask the issue.

@wagnerluis1982

This comment has been minimized.

wagnerluis1982 commented Feb 9, 2018

Hi, I'd love to contribute to pytest.

My first contribution is checking if this issue is still relevant 😄. In my machine I can't reproduce this bug. I'm using the last version (3.4.0).

@davehunt

This comment has been minimized.

Contributor

davehunt commented Feb 9, 2018

Sorry @wagnerluis1982 this was already resolved by #3147

@davehunt davehunt closed this Feb 9, 2018

@nicoddemus

This comment has been minimized.

Member

nicoddemus commented Feb 9, 2018

@wagnerluis1982 thanks for your interest in contributing, we really appreciate it. Triaging issues to see if they are still relevant (like you did now) is something that's also very helpful. 😁

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment