Skip to content
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

Closed
mdshw5 opened this issue Jan 7, 2020 · 10 comments
Labels
Milestone

Comments

@mdshw5
Copy link

@mdshw5 mdshw5 commented Jan 7, 2020

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.

  1. What version of Python are you using?
    3.5-3.7. For some reason 3.4 does not exhibit this issue.
  2. What version of coverage.py are you using? The output of coverage debug sys is helpful.
    I will try to figure this out.
  3. What versions of what packages do you have installed? The output of pip freeze is helpful.
  4. What code are you running? Give us a specific commit of a specific repo that we can check out.
    https://travis-ci.org/mdshw5/pyfaidx/jobs/633813559#L998
  5. What commands did you run?
    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.
@mdshw5 mdshw5 added the bug label Jan 7, 2020
@mdshw5

This comment has been minimized.

Copy link
Author

@mdshw5 mdshw5 commented Jan 7, 2020

This is seemingly related to #915, and discussion should continue here.

@nedbat

This comment has been minimized.

Copy link
Owner

@nedbat nedbat commented Jan 7, 2020

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! :)

@mdshw5

This comment has been minimized.

Copy link
Author

@mdshw5 mdshw5 commented Jan 7, 2020

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.

$ diff <(curl https://api.travis-ci.org/v3/job/623223954/log.txt) <(curl https://api.travis-ci.org/v3/job/633813559/log.txt)

Here is the result in diff format

mdshw5 added a commit to mdshw5/pyfaidx that referenced this issue Jan 7, 2020
This is a mitigation for nedbat/coveragepy#916
@nedbat

This comment has been minimized.

Copy link
Owner

@nedbat nedbat commented Jan 7, 2020

@mdshw5 I've reproduced the problem with your repo. A fix will happen soon, thanks.

@nedbat

This comment has been minimized.

Copy link
Owner

@nedbat nedbat commented Jan 7, 2020

@mdshw5 You can pin to 5.0.1, it works fine.

@mdshw5

This comment has been minimized.

Copy link
Author

@mdshw5 mdshw5 commented Jan 7, 2020

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 :).

@nedbat

This comment has been minimized.

Copy link
Owner

@nedbat nedbat commented Jan 8, 2020

This is fixed in e4b8389

@nedbat nedbat added the fixed label Jan 8, 2020
@nedbat nedbat added this to the 5.0.3 milestone Jan 8, 2020
@mdshw5

This comment has been minimized.

Copy link
Author

@mdshw5 mdshw5 commented Jan 8, 2020

I'll unpin the version of coverage in my module and mention this issue to confirm the fix works for me.

mdshw5 added a commit to mdshw5/pyfaidx that referenced this issue Jan 10, 2020
This should confirm the fix for nedbat/coveragepy#916
mdshw5 added a commit to mdshw5/pyfaidx that referenced this issue Jan 10, 2020
Testing again for nedbat/coveragepy#916
mdshw5 added a commit to mdshw5/pyfaidx that referenced this issue Jan 10, 2020
@mdshw5

This comment has been minimized.

Copy link
Author

@mdshw5 mdshw5 commented Jan 10, 2020

@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!

@nedbat

This comment has been minimized.

Copy link
Owner

@nedbat nedbat commented Jan 12, 2020

This is now available in 5.0.3: https://pypi.org/project/coverage/5.0.3/

rtobar added a commit to ICRAR/ngas that referenced this issue Jan 13, 2020
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.