Closed iroussos closed 3 years ago
nedbat
commented
4 years ago Thanks. I worked through how to get the latest versions of everything, and found a single test that reproduces the problem (below). @ionelmc can you take a look to figure out why pytest-cov gets this error when "coverage combine" doesn't?
sashkab
commented
4 years ago Any updates on this? I've just attempted to upgrade to the latest (5.1) version of coverage and run into similar crash. Only difference I've noticed, that path for the src file was in the wrong directory -- function which was tested changed current work dir. Can this be somehow related?
nedbat
commented
4 years ago @sashkab Are you using pytest-cov? Can you give us a way to reproduce your scenario?
sashkab
commented
4 years ago Are you using pytest-cov?
Yes.
Can you give us a way to reproduce your scenario?
I don't think it would be possible, as it is an internal project.
For the record:
test_1 | platform linux -- Python 3.6.10, pytest-4.5.0, py-1.8.1, pluggy-0.13.1
test_1 | plugins: pyq-1.2.0, cov-2.7.1Perhaps issue is with the source paths matching in the .coveragerc. Removing one of the paths from the section resulted in successful test run.
nedbat
commented
4 years ago @sashkab thanks, that could be a useful clue. Can you show us your .coveragerc, and what change you made?
sashkab
commented
4 years ago Here is my .coveragerc and I removed whole [paths] section.
[run]
omit = */tests/*
[report]
exclude_lines =
pragma: no cover
raise AssertionError
raise NotImplementedError
if __name__ == .__main__.:
ax = plt.gca()
[paths]
source =
src
.tox/*/lib/python*/site-packages
*/builds/*/XXX/src
/tox/*/lib/python*/site-packages
/code/srcLater I started to add one-by-one and still cannot figure out why/how coverage was able to find source code in the path which is basically tmp_path in pytest.
ionelmc
commented
4 years ago So this only happens if you mess with the CWD from a fixture? Does changing the fixture to be function-scoped and also undo the cwd change in the finalizer make the problem go away?
sashkab
commented
4 years ago @ionelmc code we test will change cwd, not fixtures, and not tests. My understanding this is acceptable and we didn't preserve cwd. Yesterday, I went and found most of these tests and added fixture which preserves cwd. This somewhat helped: on macOS and FreeBSD runners it resolved the INTERNALERROR, but on Linux runners I still end up with the KeyError, and it is path to the projects __init__.py file and unable to figure out where else to look.
Any suggestions on how to debug this further would be appreciated.
ionelmc
commented
4 years ago Maybe you have other places that don't undo the cwd change. I guess pytest-cov could force the right cwd when it invokes coverage, hmmm.
sashkab
commented
4 years ago Maybe you have other places that don't undo the cwd change.
I definitely have, but my project is huge -- taking time to find all of them.
I guess pytest-cov could force the right cwd when it invokes coverage, hmmm.
I guess it might not be needed, as os.getcwd() reports correct path at this point.
sashkab
commented
4 years ago I'm somewhat confused. So I end up in line 117 of data.py with
data.update(new_data, aliases=aliases)where new_data points to an empty (??) sqlite3 file. How it gets any path here? Is there some kind of magic with aliases?
sqlite> select * from arc;
sqlite> select * from coverage_schema;
7
sqlite> select * from line_bits;
sqlite> select * from tracer;
sqlite> select * from context;
sqlite> select * from file;
sqlite> select * from meta;
sys_argv|['/tmp/pytest-of-gitlab-runner/pytest-8202/test_start_server0_primary_0/gateway', '/tmp/pytest-of-gitlab-runner/pytest-8202/test_start_server0_primary_0/test_config']
version|5.1
when|2020-05-21 16:03:00
has_arcs|0(sorry, I missed time to step into data.update and too tired to repeat this again. If you can suggest what else should I look for -- will appreciate)
ionelmc
commented
4 years ago Alright, next release of pytest-cov will have a fix.
sashkab
commented
4 years ago Preliminary testing suggests that issue is fixed after upgrading to pytest-cov 2.9.0.
Thanks @ionelmc!
davisagli
commented
3 years ago For what it's worth: I had a similar error which I tracked down to a bug in newrelic's instrumentation of sqlite: https://github.com/newrelic/newrelic-python-agent/issues/179
Strangely, in my case the error started happening when we updated to pytest-cov 2.9.0
Describe the bug Since v5.0 was released on PyPi, we are getting the following error:
To Reproduce
How can we reproduce the problem? Please be specific.
Python 3.6
coverage debug sysis helpful.Latest on PyPi --> 5.0 (coverage-5.0-cp36-cp36m-manylinux1_x86_64.whl)
pip freezeis helpful.You can check our full
pip install '.[dev]'log in our runner's log together with the pytests and the coverage run afterwards:https://gitlab.com/meltano/meltano/-/jobs/379770331
https://gitlab.com/meltano/meltano/blob/master/.gitlab/ci/test.gitlab-ci.yml#L46
We are running coveragepy as part of our automated tests after our pytests are done:
Expected behavior This was running without issues on the latest pre v5.0 stable release.