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.
It would be nice if Koschei could build against updates-testing so that problems like this could be more easily detected before the updates have already reached stable.
– Ben
[1] https://bodhi.fedoraproject.org/updates/FEDORA-2021-3b53235332 [2] https://bodhi.fedoraproject.org/updates/FEDORA-2021-379e60a35b
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 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...
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.
Also, if you don't like the repeated slightly different command, it can be factored out, but I considered that less readable.
On Sat, 2021-12-18 at 11:49 +0100, Miro Hrončok wrote:
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] ...
Hmm, that might work, yeah. I'm not *sure* whether I like it more, heh.
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.
Yeah, I suppose in a way it'd make sense to separate them, just never thought about it.
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].
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2033331
On 12/16/21 14: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.
It would be nice if Koschei could build against updates-testing so that problems like this could be more easily detected before the updates have already reached stable.
– Ben
[1] https://bodhi.fedoraproject.org/updates/FEDORA-2021-3b53235332 [2] https://bodhi.fedoraproject.org/updates/FEDORA-2021-379e60a35b
On Thu, 2021-12-16 at 22:08 -0500, Ben Beasley wrote:
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].
This should be resolved when https://bodhi.fedoraproject.org/updates/FEDORA-2021-1e86cbf275 goes stable.
On Thu, Dec 16, 2021 at 3:54 PM Ben Beasley code@musicinmybrain.net 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.
It's been screwing up "mock" builds for Fedora 34 and Fedora 35, as well. It's one of the risks of many python modules, with a requirement.txt like "ansible-core<2.13,>=2.12.0", but do not necessarily list a maximum value range or a completely valid minimum value for their dependencies. Hilarity ensues.
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.
It would be nice if Koschei could build against updates-testing so that problems like this could be more easily detected before the updates have already reached stable.
– Ben
[1] https://bodhi.fedoraproject.org/updates/FEDORA-2021-3b53235332 [2] https://bodhi.fedoraproject.org/updates/FEDORA-2021-379e60a35b _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure