Stricter Versioning For Coverage

[HassanAbouelela]

The latest release of coveralls is failing due to an internal change in coverage.py. That is addressed in #333. This isn't the first time this happens though, with #326 and #203 being other examples I could find with a quick search. I've also personally run into this in the past, but I don't think I've ever reported it.

I'm basically making the same suggestion as #327 (it was closed with no further discussion as far as I could tell). These problems are not necessarily the fault of this package, nor coverage.py, they just come with the territory, but having very strict compatibility would prevent this from happening. All that would really need doing is to lock the max version specifically, to ensure future updates of coverage don't inexplicably break the package.

If we consider the situation under which this package is used (mostly after a developer is ready to call something "done", usually in CI), having this package rely on very specific versions of coverage doesn't seem like too big a deal. I think it's much less problematic than having your CI pipelines fail unexpectedly every now and then.

Love what you're doing here, and I hope you consider strategies for avoiding this problem. Thanks!

[TheKevJames]

Thanks for the report! Max coverage version is now explicitly locked in dependencies and this will be handled correctly in future releases of coveralls. Note that there are a couple places where we need to reach into the internals of coverage -- since those aren't covered under the public contract, even patch versions of coverage could cause issues. I've opened #420 to track this explicitly.