Backwards incompatible debug change

[cdce8p]

Describe the bug
The change done in 16f54a9 (adding a name argument to TreeMatcher, ModuleMatcher, and FnmatchMatcher) makes it difficult for projects to support both versions 5.x and 6.x as the signature is incompatible.

For example coveralls-python doesn't currently pass the name argument.
https://github.com/TheKevJames/coveralls-python/blob/e03a2de15e65cafc3fe583b1ab15e3e0b6478722/coveralls/reporter.py#L70-L78

This obviously results in a TypeError when using 6.x: TheKevJames/coveralls-python#333

Possible resolutions

1. coveralls-python could drop support for 5.x.
2. It could detect the version of coveragepy and act accordingly.
3. Or a default value is added to TreeMatcher, ModuleMatcher, and FnmatchMatcher.

Although options (1) and (2) would work, I think (3) is be preferable. name is only used in the __repr__ functions. I don't think that justifies breaking existing code.

[nedbat]

Another possible resolution:

4. Stop using internal undocumented interfaces, and ask for support for the features you need.

A default value is not unreasonable, but it is tiresome having to think about people using undocumented interfaces.

[cdce8p]

Another possible resolution:

1. Stop using internal undocumented interfaces, and ask for support for the features you need.

A default value is not unreasonable, but it is tiresome having to think about people using undocumented interfaces.

True. Although I only debugged the error, I know this to all to well from my own experience in Open Source.

[DanielNoord]

Thanks @nedbat I saw the discussion in the original issue about coveralls-python and coveragepy 6.0 which is why I reported against them initially.
Completely agree with you and very grateful that you are willing to take this up! Much appreciated!

[nedbat]

Fixed in e3e637c. (it's nicer with the default value anyway...)

[nedbat]

This is now released as part of coverage 6.1.2.

[TheKevJames]

Hey @nedbat, coveralls-python maintainer here. Sorry for the issues this caused! I'd thought I managed to switch away from using any undocumented internal coverage-py functionality back around the v5 release, but I'd forgotten entirely about some of the workarounds we still needed. It looks like you've actually tackled a couple of the things we were relying on recently anyway, so now is definitely the right time for me to take a look.

The gist of the issue is described here. We're pretty close to being able to use get_analysis_to_report directly, and it looks like the config.ignore_errors boolean is the last piece.

What are your thoughts on coveralls-python setting ignore_errors=True unconditionally? I've erred away from doing so as I really only wanted to avoid errors in this specific function call, but I don't want to affect behavioural changes to coverage-py in eg. places like this. What are your thoughts on expected usage here?

The only other (minor!) question would be whether this exception could be made more granular. There are plenty of other CoverageExceptions which we wouldn't want to catch, but this one is OK for our use-case. Note this is just a nitpick, I could certainly do except CoverageException as e: if str(e) != 'No data to report.': raise or such, but it throwing, say, a NoDataException might be easier to reason about.

[nedbat]

About ignoring errors: you can certainly do that if you want, you know your users' needs.

About exceptions: good idea! I've sliced them up better in commit 1c29ef3. Let me know if it looks like what you were thinking.