Ensure that CTracer is installed on CPython 3.14 by default

[manueljacob]

When installing coverage 7.8.2 via pip on CPython 3.9 to CPython 3.13, it will by default install a wheel that includes CTracer. However, when installing on CPython 3.14, coverage-7.8.2-py3-none-any.whl will be installed. This is not optimal because it doesn’t contain CTracer although it would work on CPython 3.14.

I see two solutions:

1. Publish wheels for CPython 3.14. Given that CPython 3.14 is now in beta, this may be justified. However, it might not be a good idea to do the same for future alpha releases (CPython 3.15 and above).
2. Don’t publish an universal wheel. I think this will cause CTracer to be build on CPython 3.14. This is in conflict with the goal of Add py3-none-any wheel to distribution artefacts #1912. That issue said that “[publishing a py3-none-any wheel] would only affect users on niche platforms”. However, it also affects users of CPython 3.14 on mainstream platforms. Maybe there’s some solution solving both problems. (CC @freakboy3742)

A workaround is to disable wheels when installing coverage on CPython 3.14. However, that will always build from source, even when wheels including CTracer become available in the future.

[freakboy3742]

There's a third option: build a binary wheel locally (python3.14 pip wheel coveragepy), and make that wheel available to your local install with pip install -f local_wheels (or similar).

I'd argue that during the alpha (and even beta) phase of a Python lifecycle, that would be the preferable approach - ABI compatibility isn't guaranteed until late in the release cycle; formally publishing binary wheels before that point is definitely premature.

[nedbat]

The guidance from cibuildwheel is as @freakboy3742 says: don't build wheels until the rc stage. See the Caution box here: https://cibuildwheel.pypa.io/en/stable/options/#enable

I'm open to other ideas.

[ThomasWaldmann]

Related problem: it breaks some tests that rely on specific stdout/stderr contents by emitting that warning:

          +     '/home/runner/work/borg/borg/.tox/py314-fuse3/lib/python3.14/site-packages/coverage/core.py:96: '
E         +     "CoverageWarning: Couldn't import C tracer: No module named "
E         +     "'coverage.tracer' (no-ctracer)",
E         +     'stderr: warn(f"Couldn\'t import C tracer: {IMPORT_ERROR}", '
E         +     'slug="no-ctracer", once=True)',

I thought I could easily start testing using "3.14-dev" on github actions CI, but now I can't due to coverage breaking these tests.

[nedbat]

@ThomasWaldmann you can suppress that warning:

[tool.coverage.run]
disable_warnings = [
    "no-ctracer",
]

https://coverage.readthedocs.io/en/7.9.0/config.html#run-disable-warnings

[henryiii]

If you have warnings as errors by default (which is very good practice!), this breaks 3.14 testing. I'm having to add the above warning suppression to every project I work on. One thought is this warning could be disabled if there are no known binaries for a platform (like 3.14)? Though I hadn't thought of building the wheel myself.

As for the binary wheels, technically in the past CPython has declared ABI stability on the last beta, beta 4, cibuildwheel just uses RC 1 as the point when it's enabled by default as it's simpler to communicate. So if that's still true this year, you could release binaries a few weeks before RC 1. I don't know if free-threading has the same ABI freeze point.

The official CPython recommendation is to produce dev releases with binary wheels for 3.14, but I don't like that, as the release cycle of a library (like coverage in this case) isn't tied to CPython releases. The solution the scientific libraries have adopted is to have a second wheelhouse for nightlies (https://pypi.anaconda.org/scientific-python-nightly-wheels/simple, see https://scientific-python.org/specs/spec-0004/). You can get numpy 3.14 binaries from there, for example.

There is one more recommendation I've heard, and that is to make binaries, but then be ready to reupload them with a bumped build number (wheel's cli lets you do that to an existing wheel) if ABI changes. I don't think I've seen any packages willing to do that, and potentially have to reupload multiple past releases.

[nedbat]

I've released 7.9.1 which won't warn on 3.14. It also defaults to sys.monitoring on 3.14, so test runs should be faster. As always, let me know if something seems bad.