extra space in INI markers section causes inconsistent behavior

[greg78731]

In the markers section of the INI file, if you include an extra space between the marker and the colon, the pytest --markers command lists the marker, however the running pytest -m mymarker causes an "Attribute Error: 'mymarker' not a registered marker.

pytest.ini example:

[pytest] 
addopts = -rsxX -l --strict -v -x

markers = 
	incomplete: tests which are not complete
	dev : tests in development
	complete: tests which are complete
	noDbUpdate: tests which do not update the database

filterwarnings =
    ignore

NOTE: There's an extra space between dev and the colon.

pytest --markers lists:

> pytest --markers
@pytest.mark.incomplete: tests which are not complete

@pytest.mark.dev : tests in development

@pytest.mark.complete: tests which are complete

@pytest.mark.noDbUpdate: tests which do not update the database

pytest -m dev generates:

>pytest -m dev
============================= test session starts =============================
platform win32 -- Python 3.4.3, pytest-3.2.3, py-1.4.34, pluggy-0.4.0 -- c:\python34\python.exe
cachedir: .cache
rootdir: C:\Users\Greg\...\tests, inifile: pytest.ini
collecting 0 items / 1 errors
=================================== ERRORS ====================================
___________________ ERROR collecting test_createShipment.py ___________________
test_createShipment.py:127: in <module>
    @pytest.mark.dev
c:\python34\lib\site-packages\_pytest\mark.py:264: in __getattr__
    self._check(name)
c:\python34\lib\site-packages\_pytest\mark.py:279: in _check
    raise AttributeError("%r not a registered marker" % (name,))
E   AttributeError: 'dev' not a registered marker
!!!!!!!!!!!!!!!!!!! Interrupted: stopping after 1 failures !!!!!!!!!!!!!!!!!!!!
=========================== 1 error in 1.06 seconds ===========================

Version info:
Python 3.4.3 running on Windows 10.0.14393
pytest version 3.2.3

[nicoddemus]

Why do you consider this a backward compatibility issue @RonnyPfannschmidt ? I find it hard to believe somebody actually depends on that behavior...

[RonnyPfannschmidt]

@nicoddemus yes - but we are bascially going to change a parser and the fix may break other working code ^^

[nicoddemus]

OK I see what you mean. So this probably belongs in the features branch.