-
-
Notifications
You must be signed in to change notification settings - Fork 440
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
coverage.misc.CoverageException: Couldn't use data file '/path/to/.coverage': no such table: meta #916
Comments
This is seemingly related to #915, and discussion should continue here. |
Thanks, I can try to reproduce this, though it looks like you have some tricky things to install. The more detailed you can make the instructions, the higher my success rate. PS: You should come to Boston Python! :) |
Thanks @nedbat. I'll work on a minimal reproducible example tonight when I have time. I do see that my builds that were previously passing were using coverage-4.5.4, and the same commit that now fails when triggered manually (or by a cron job in this case) is using coverage-5.0.2. A diff of the logs shows that very little has changed other than the coverage version and the numpy version. For right now I'm going to pin my coverage version at 4.5.4, and can try to update with more info you might need to reproduce this.
|
This is a mitigation for nedbat/coveragepy#916
@mdshw5 I've reproduced the problem with your repo. A fix will happen soon, thanks. |
@mdshw5 You can pin to 5.0.1, it works fine. |
Thanks @nedbat. I've actually been to Boston Python once in the past, about 5 years ago, and have been meaning to start going for some time. Seems like a great group, and now that my kids are a bit older, and I can stay in the city a bit later after work (I commute from a north shore suburb) I'll make more of an effort to show up :). |
This is fixed in e4b8389 |
I'll unpin the version of coverage in my module and mention this issue to confirm the fix works for me. |
This should confirm the fix for nedbat/coveragepy#916
Testing again for nedbat/coveragepy#916
@nedbat Thanks for pushing changes to fix this issue. I can confirm that the current master fixes the problem for me, and I look forward to a 5.0.3 release on PyPI! |
This is now available in 5.0.3: https://pypi.org/project/coverage/5.0.3/ |
Issues with the latest coverage package versions (see nedbat/coveragepy#916 for an example) are preventing us from seeing the actual errors our pipeline has. Pinning down to latest known working version, will remove the constraint when the package is stable again. Signed-off-by: Rodrigo Tobar <rtobar@icrar.org>
* Update CI to use Python versions 3.7 and 3.10 * surround 3.10 with quotes to treat as string * unpin coverage version * remove obsolete Python 2 related imports * pin coverage package due to nedbat/coveragepy#916 * pin coveragepy to 5.0.3 * run coverage in parallel mode, combine coverage report, and add type annotation for chunk_layout * append coverage data only during combine and not run * output test logs if make check fails
Describe the bug
This bug bit me this morning when old TravisCI builds reported failing suddenly with no code changes in my library. https://travis-ci.org/mdshw5/pyfaidx/jobs/633813559#L1187.
To Reproduce
How can we reproduce the problem? Please be specific.
3.5-3.7. For some reason 3.4 does not exhibit this issue.
coverage debug sys
is helpful.I will try to figure this out.
pip freeze
is helpful.https://travis-ci.org/mdshw5/pyfaidx/jobs/633813559#L998
nosetests --with-coverage --cover-package=pyfaidx
Expected behavior
A clear and concise description of what you expected to happen.
I expected coverage to be computed instead of a runtime error.
Additional context
I'll gladly provide more context where I can - I'm still reasoning about how to reproduce a Travis build locally.
The text was updated successfully, but these errors were encountered: