Add support for coverage v5.0+

[davidwagner]

Running coveralls or coveralls debug or coveralls debug --verbose gives me the following stack dump:

Testing coveralls-python...
Traceback (most recent call last):
  File "/tmp/ds/bin/coveralls", line 10, in <module>
    sys.exit(main())
  File "/tmp/ds/lib64/python3.7/site-packages/coveralls/cli.py", line 68, in main
    coverallz.wear(dry_run=True)
  File "/tmp/ds/lib64/python3.7/site-packages/coveralls/api.py", line 168, in wear
    json_string = self.create_report()
  File "/tmp/ds/lib64/python3.7/site-packages/coveralls/api.py", line 184, in create_report
    data = self.create_data()
  File "/tmp/ds/lib64/python3.7/site-packages/coveralls/api.py", line 238, in create_data
    self._data = {'source_files': self.get_coverage()}
  File "/tmp/ds/lib64/python3.7/site-packages/coveralls/api.py", line 260, in get_coverage
    return CoverallReporter(workman, workman.config).report()
  File "/tmp/ds/lib64/python3.7/site-packages/coveralls/reporter.py", line 47, in report
    self.parse_file(cu, analyzed)
  File "/tmp/ds/lib64/python3.7/site-packages/coveralls/reporter.py", line 158, in parse_file
    branches = self.get_arcs(analysis)
  File "/tmp/ds/lib64/python3.7/site-packages/coveralls/reporter.py", line 103, in get_arcs
    branch_lines = analysis.branch_lines()
AttributeError: 'Analysis' object has no attribute 'branch_lines'

This is with coverage 5.0a5 and coveralls 1.8.0. It looks to me like the coverage library recently changed branch_lines to _branch_lines in the Analysis class (see nedbat/coveragepy@f869f4d#diff-b696f62d55a35f1f75a13c5c7ecf2f68), and coveralls is still trying to access it under the old name. I think. Or maybe the issue is on my end; I don't know.

[TheKevJames]

Yup, that looks like its definitely an issue with changes coverage v5+ has made that we're not ready for. For now, you can make sure things are working by pinning to coverage <5 in your requirements file.

That looks like exactly the right solution, too. We'll need to add more fallback code like we do elsewhere. I'll probably want to avoid releasing any changes like that until Coverage is past alpha releases, in case more things change, but I'd be happy to accept a partial PR with this part for now.

I'll add a coverage <5 pin for now.

[TheKevJames]

I've release version 1.8.1 with an explicit pin to prevent this issue. Leaving this issue open as a "TODO: fix coverage>=5.0 support"

[blueyed]

JFI: it might be good if coveralls-python could be passed in a coverage.xml file directly already.

I have the case where I am testing against/with Coverage.py 5 myself (with https://github.com/Vimjas/covimerage), and then coveralls-python cannot be used to report the data.

This would be useful of course also already when you are running coverage xml manually before, e.g. when uploading it to multiple services.

[TheKevJames]

@blueyed I'd be happy to accept a PR which introduces that functionality, but I don't personally find myself having much time to work on this project. For now, my plan is to avoid supporting coverage v5.0+ until they hit a non-prerelease version (they recently hit their first beta version after eight alphas, so I suspect that will be soon!)

[nedbat]

Coverage.py 5.0 was released yesterday. :)

[nedbat]

BTW, if there's something missing from the documented supported API, let me know. Using undocumented classes is bound to be difficult down the road.

[espdev]

Since coverage 5.0 was released my CI was broken because it uses pip.
pip install pytest-cov coveralls command creates broken environment at the moment:

ERROR: coveralls 1.9.2 has requirement coverage<5.0,>=3.6, but you'll have coverage 5.0 which is incompatible.
Installing collected packages: coverage, pytest-cov, coveralls
Successfully installed coverage-5.0 coveralls-1.9.2 pytest-cov-2.8.1

I know, pip does not resolve dependencies unlike poetry or dephell and this is not coveralls issue, but it is unpleasant anyway.

I have changed the configuration for using the following install command:

pip install coverage==4.5.4 pytest-cov coveralls

It works, and I still hate packaging in Python.

[MuellerSeb]

I'll use:

pip install coverage~=4.5.4

for now.

[thibaudcolas]

I’ve had a similar issue on my project, although with a different stack trace / error message, which I’ll copy here in case it helps others track down the issue.

coverage.misc.CoverageException: Couldn't read data from .coverage': UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb0 in position 99: invalid start byte

Full stack trace

Traceback (most recent call last):
  File "/home/travis/virtualenv/python3.8.0/lib/python3.8/site-packages/coverage/data.py", line 293, in read_file
    self.read_fileobj(f)
  File "/home/travis/virtualenv/python3.8.0/lib/python3.8/site-packages/coverage/data.py", line 271, in read_fileobj
    data = self._read_raw_data(file_obj)
  File "/home/travis/virtualenv/python3.8.0/lib/python3.8/site-packages/coverage/data.py", line 311, in _read_raw_data
    go_away = file_obj.read(len(cls._GO_AWAY))
  File "/home/travis/virtualenv/python3.8.0/lib/python3.8/codecs.py", line 322, in decode
    (result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb0 in position 99: invalid start byte
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "/home/travis/virtualenv/python3.8.0/bin/coveralls", line 8, in <module>
    sys.exit(main())
  File "/home/travis/virtualenv/python3.8.0/lib/python3.8/site-packages/coveralls/cli.py", line 77, in main
    result = coverallz.wear()
  File "/home/travis/virtualenv/python3.8.0/lib/python3.8/site-packages/coveralls/api.py", line 176, in wear
    json_string = self.create_report()
  File "/home/travis/virtualenv/python3.8.0/lib/python3.8/site-packages/coveralls/api.py", line 192, in create_report
    data = self.create_data()
  File "/home/travis/virtualenv/python3.8.0/lib/python3.8/site-packages/coveralls/api.py", line 246, in create_data
    self._data = {'source_files': self.get_coverage()}
  File "/home/travis/virtualenv/python3.8.0/lib/python3.8/site-packages/coveralls/api.py", line 261, in get_coverage
    workman.load()
  File "/home/travis/virtualenv/python3.8.0/lib/python3.8/site-packages/coverage/control.py", line 677, in load
    self.data_files.read(self.data)
  File "/home/travis/virtualenv/python3.8.0/lib/python3.8/site-packages/coverage/data.py", line 653, in read
    data.read_file(self.filename)
  File "/home/travis/virtualenv/python3.8.0/lib/python3.8/site-packages/coverage/data.py", line 295, in read_file
    raise CoverageException(
coverage.misc.CoverageException: Couldn't read data from '/home/travis/build/springload/draftjs_exporter/.coverage': UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb0 in position 99: invalid start byte

[TheKevJames]

Version 1.10.0 of coveralls is now rolling out onto PyPI (conda rollout shortly) with support for coverage>=5.0. Y'all should now be able to unpin your coverage versions. Closing this issue -- please let me know if anyone has issues with the new release!

For those interested: the PR for v5.x support is #214. @nedbat looks like the only private API I had to access was this one -- any thoughts on how I might do that better?

@thibaudcolas if I understand correctly, coverage v5.x changed the on-disk format of the .coverage file -- I know I ran into some issues with cached copied of .coverage from v4.x not interoperating with v5.x properly. Perhaps nuke the file and see if you still get the issue? Please let me know if you're still seeing any problems once you upgrade to v1.10.0+ of coveralls.

[thibaudcolas]

Yup, this is now working as expected, with coverage==5.0.1 and coveralls==1.10.0. Thank you!