I'm trying to direct all test and coverage output to a single .cache directory in my project, but pytest won't respect the cache_dir option I'm setting to .cache/pytest and keeps creating .pytest_cache instead. This used to work fine in another project with pytest 3.3.0.
$ cat setup.cfg
[pycodestyle]
ignore = E123,E126,E501
[tool:pytest]
testpaths = tests
cache_dir = .cache/pytest
[coverage:run]
branch = True
source = snlint
data_file = .cache/cov/coverage
[coverage:report]
show_missing = True
sort = Name
exclude_lines =
# Have to re-enable the standard pragma
pragma: no cover
# Don't complain about missing debug-only code:
def __repr__
if config\.debug
# Don't complain if tests don't hit defensive assertion code:
raise AssertionError
raise NotImplementedError
assert 0
assert False
# Don't complain if non-runnable code isn't run:
if 0:
if False:
if __name__ == .__main__.:
[coverage:html]
directory = .cache/cov/cov_html
[coverage:xml]
output = .cache/cov/cov.xml
$ pytest \
-c setup.cfg \
-vv \
--cov snlint \
--cov-config setup.cfg \
--cov-report html \
--cov-report xml \
--cov-report term-missing
============================================================================================================================================================================ test session starts ============================================================================================================================================================================
platform linux -- Python 3.6.3, pytest-3.4.1, py-1.5.2, pluggy-0.6.0 -- /home/sonaxaton/.local/share/virtualenvs/snlint-so_H9yU2/bin/python3.6
cachedir: .pytest_cache
rootdir: /home/sonaxaton/Dropbox/Programming/python/snlint, inifile: setup.cfg
plugins: cov-2.5.1
...
$ pip list
Package Version
---------------- -------
attrs 17.4.0
click 6.7
coverage 4.5.1
pip 9.0.1
pluggy 0.6.0
py 1.5.2
pycodestyle 2.3.1
pytest 3.4.1
pytest-cov 2.5.1
setuptools 38.5.1
six 1.11.0
sortedcontainers 1.5.9
wheel 0.30.0
I take it :)
Cool @feuillemorte, thanks! (In the future feel free to assign yourself to the issues if you want :wink:)
reproduced only with option "-c setup.cfg"
Seems that problem is in setup.cfg file:
[tool:pytest]
testpaths = tests
cache_dir = .cache/pytest
[tool:pytest] instead of [pytest]. If you fix it it will work fine:
cachedir: .cache/pytest
rootdir: /home/username/github/pytest-dev/pytest/pytest_3260, inifile: tests/setup_new.cfg
The problem is here:
https://github.com/pytest-dev/pytest/blob/44fa5a77d4544d22220704fab5ab494fb57f52ae/_pytest/config.py#L1326-L1349
Code goes in the first "if" and not calls getcfg function (which parses [tool:pytest] section) because inifilename defined by "-c" option:
def determine_setup(inifile, args, warnfunc=None):
dirs = get_dirs_from_args(args)
print('INI', inifile)
prints me
INI tests/setup_new.cfg
@nicoddemus is it a bug or smth was changed from 3.3.0 version?
@feuillemorte thanks for the investigation! Now I see that this is actually a duplicate of #1831.
I think we should change that line to inicfg = iniconfig["tool:pytest"] when we are dealing with .cfg files, something like:
section = 'tool:pytest' if inifile.ext == '.cfg' else 'pytest'
try:
inicfg = iniconfig[section]
except KeyError:
inicfg = None
But section might be [tool:pytest] or [pytest] in .cfg file, isn't it?
Oh you are right, so we need to have a list of possible sections then, and check each one.
The current docs on this are unclear or pointing towards it being [tool:pytest], hence my confusion. I think they need to be updated as well to reflect whatever comes out of this. Also, [tool:pytest] should be preserved for backwards-compatibility.
@dbeckwith you are right, just to be clear:
setup.cfg files support [tool:pytest] (recommended) and [pytest] (deprecated, scheduled to be removed in #3086).tox.ini and pytest.ini support [pytest].EDIT: the bug here is that -c setup.cfg is not recognizing [tool:pytest], when in fact it should.
Okay, and the I guess the issue I was running into was that specifying the file with -c made it assume it was just some random config file and not setup.cfg?
Okay, and the I guess the issue I was running into was that specifying the file with -c made it assume it was just some random config file and not setup.cfg?
Exactly. If you don't pass -c then your example works as @feuillemorte mentioned, but this is a bug that we should fix.