On 16. 12. 21 20:09, Ben Beasley wrote: > It looks like python-pytest-cov was recently updated to 3.0.0 in F35[1] and > F34[2]. I noticed this because, between my own packages and those maintained > through @neuro-sig, I saw a wave of FTBFS notifications from Koschei. > > Unfortunately, because packages commonly pin a particular major version, and > because pytest-cov has been in 2.x for a long time, a huge number of packages > are likely to be affected. A good opportunity to patch/sed coverage out of those packages for good :)

On 17. 12. 21 21:41, Adam Williamson wrote: > On Thu, 2021-12-16 at 21:53 +0100, Miro Hrončok wrote: > > On 16. 12. 21 20:09, Ben Beasley wrote: > > > It looks like python-pytest-cov was recently updated to 3.0.0 in F35[1] and > > > F34[2]. I noticed this because, between my own packages and those maintained > > > through @neuro-sig, I saw a wave of FTBFS notifications from Koschei. > > > > > > Unfortunately, because packages commonly pin a particular major version, and > > > because pytest-cov has been in 2.x for a long time, a huge number of packages > > > are likely to be affected. > > > > A good opportunity to patch/sed coverage out of those packages for good :) > > FWIW, I use a pattern in several projects I maintain where tests are > always run via coverage, although actually generating and analyzing > reports is only done in a tox environment that is run in CI workflows > (and not in the package build). See: > https://pagure.io/fedora-qa/fedfind/blob/main/f/tox.ini > for e.g. If you have a better way to do this, let me know... Something like this (untested). [tox] envlist = {py27,py36,py38,py39,py310,py311}{-coverage,},coverage-report ... [testenv] deps = -r{toxinidir}/install.requires -r{toxinidir}/tests.requires coverage: -r{toxinidir}/tests-coverage.requires commands = python -m pytest {posargs} [testenv:coverage] commands = coverage run -m pytest {posargs} [testenv:coverage-report] ...

I would personally not mix coverage report and linting, but from downstream perspective, it doesn't matter becasue that is what we don't run either way.

It turns out that while a couple of packages I care about were actually broken by the bump to 3.0, most of them were instead broken by the update failing to install on F34[1].