Fix the combined coverage report

[rudaporto]

Reworked on top of current master.

The original 2022 branch could not be rebased: it targeted Python 3.6–3.11,
[coverage:run] sections that have since moved into pyproject.toml,
actions/*@v2, and a pip-based CI that has since moved to uv. The analysis
in the original PR was correct and is what this implements — credit to
@rudaporto.

The bug

combined-coverage depended on the coverage environment and both wrote to
.coverage, so its coverage erase destroyed the data it was meant to
combine — including the Sphinx doctest coverage, which was measured nowhere
else. It also omitted py315 from depends and hard-coded
--fail-under=100 on the command line, contradicting fail_under = 97.1 in
pyproject.toml. On top of that, the coverage environment re-ran the whole
test suite that the per-version environments had just run.

What changed

• [testenv:coverage] is now the combining environment, and
  [testenv:combined-coverage] is gone. This needed no zope.meta template
  changes — the existing coverage-command and coverage-additional
  options already produce exactly the required environment.
• py315 added to depends. Note that depends orders environments in
  sequential runs too, not only under tox -p, so coverage runs last
  regardless of its position in the envlist.
• The per-version environments no longer gate on coverage
  (--cov-fail-under=0): a single Python version cannot reach 100 %, only the
  combination can. The threshold is enforced once, on the combined report.
• fail_under raised to 100 and actually met:
  • added the missing test for an ast.Expression body in
    compile_restricted_function (compile.py lines 179–181 were untested),
  • excluded the typing.overload stubs in Limits.py and the
    typing.Protocol stub in Eval.py, whose bodies never execute at runtime
    by design.
• relative_files = true so the data stays portable across machines.

Result

Combined coverage is 100.00 % over py310–py315 plus py311-datetime.
A single version reaches only 99.76 %, which is the whole point: the
version-conditional code (_types.py, the t-string and except* tests) can
only be covered by the union.

Verified locally: tox -e lint,docs,py310,py311,py312,py313,py314,py315,py311-datetime,coverage
and release-check all pass, sequentially and under tox -p auto. Combining
from a single version's data correctly fails the gate at 99.76 %.

Scope

CI still measures a single Python version. Moving CI onto the combined report
requires new zope.meta template support (there is no hook to add a step after
Test, nor to add a job), so it follows separately — see the issue filed
against zopefoundation/meta.

— Comment created by Claude

[rudaporto]

When using the matrix execution we can not collect the combined coverage from each python version.

[davisagli]

https://hynek.me/articles/ditch-codecov-python/ has a suggestion of how to do this

[dataflake]

FYI, the file .github/workflows/tests.yml is auto-generated and should not be edited by hand. It uses the meta/config package, see https://github.com/zopefoundation/meta/tree/master/config, which is configured using the .meta.toml file.

[rudaporto]

FYI, the file .github/workflows/tests.yml is auto-generated and should not be edited by hand. It uses the meta/config package, see https://github.com/zopefoundation/meta/tree/master/config, which is configured using the .meta.toml file.

Thank you @dataflake for the reminder. Yes, I know that this should not be changed directly.
I've updated the description with a full explanation of what I tried to achieve.

I will convert this PR to a draft to avoid confusion.

[icemac]

I think this approach presented here is promising. It requires some changes in meta/config so it can produce the required tests.yaml.
Currently we are running coverage just for one Python version. In most projects this is enough because (after dropping Python 2 support) there is nearly no Python version specific code. So for the other projects I think it will be enough just to run coverage on a single Python version, but here we have different goals.

I currently do not have the time and energy to push meta/config forward to be able to support the kind of changes required here, sorry.