coveralls-python
coveralls-python copied to clipboard
TheKevJames
Support for Python 2.7
Even though Python 2.7 is out of service there are many projects that still have a need to support it.
Taking that away in an important project like coveralls is no good idea. Particularly since it does not solve any problem within coveralls.
I have a PR https://github.com/andy-maier/coveralls-python/pull/1 on top of the master branch of this repo that brings back support for Python 2.7, and its GitHub Actions testcases succeed. The changes were really minimal. We have succesfully used that branch on Python 2.7 in a Github Actions based project (see https://github.com/pywbem/nocasedict/pull/68).
Please let me know whether you are willing to reintroduce support for Python 2.7 into this project. If that is not the case, no problem, then I will consider releasing a 2.7 backport version of coveralls to Pypi. I'm sorry but we simply need that support.
PS: As an alternative, I looked at the old python-coveralls as an alternative, but besides not being maintained anymore as it seems, it is behind coveralls-python in its support for CI systems, and does not combine reports with coveralls-python when running on GitHub Actions. So it is not a viable alternative for us.
I thought I should explain why we are not using coveralls 1.x on Python 2.7, and the main reason is that it does not combine reports with coverage 2.x reports, at least not on GitHub Actions. I would have no problem using coveralls 1.x on Python 2.7 (pinning it to <2.0), if it would support combining reports with coveralls 2.x. That would require at least a change in the service job ID area of 1.x, but maybe more (I did not dig to the ground of it). Let me know if you like this alternative better than a backport of 2.x to Python 2.7.
@andy-maier Though I understand that many projects may still use Python 2.7, I am not willing to commit to support for it. Though you are correct that getting a base-line level of support isn't too much effort, there's a whole slew of edge-cases and bugs which we originally had to account for when we were maintaining support (relatedly, you may find the commit where we removed support for py27 useful, as there are a few more edge-cases you may wish to account for). Being able to drop support in accordance with Python's official EOL policies has made maintenance significantly easier.
I would indeed be willing to backport the fix you mentioned to the 1.x branch, if that could make things easier! You can make branch of the 1.x branch for this.
I thought I should explain why we are not using coveralls 1.x on Python 2.7, and the main reason is that it does not combine reports with coverage 2.x reports, at least not on GitHub Actions. I would have no problem using coveralls 1.x on Python 2.7 (pinning it to <2.0), if it would support combining reports with coveralls 2.x.
That was the only frustration after migrating from Travis to Github Actions, @andy-maier patch works great. It's nice to have the option. The only other options is to simply not do coverage for <3.5. I would like to see the option available on this repo, but limited to the occasional bug patch contribution and no new FRs.
I'm also willing to help maintain a branch that supports python 2.7 and pythons < 3.5 (I actually need to support 2.6 for the next 3 years, let alone 2.7, so this is something I'll need for a long time)
currently, if I want correct compare to master branch I need to use coveralls-python 1.11.1 everywhere, which feels quite silly
I was able to build on work of @andy-maier, and make that branch work on python 2.6 and 3.3 too! The code is here (but I don't guarantee it will remain there)
And I've tested it in production here: https://github.com/tlsfuzzer/tlslite-ng/pull/458 and in the resulting merge action here: https://github.com/tlsfuzzer/tlslite-ng/actions/runs/503761385 for both runs coveralls correctly merged coverage between py2.6 and py3.9 (and all in between) and provided a correct summary coverage and change percentage of it, all while using the github token and "github" service name
so, @TheKevJames I don't think it would be too hard to keep the coveralls-python working on even the oldest pythons that still have commercial support, question is, would you prefer this to happen on master branch or on a 2.x branch?
I'm also willing to use pre-release versions of coveralls-python to make sure that those old versions don't get dropped accidentally; if you don't want to keep the CI running for those old pythons (I know very well how much effort it takes)