abi3t wheel tag from main is not accepted by current pip/packaging

[honglei]

Hi, thanks for adding abi3t support in #1269.

I searched existing issues before opening this. I found:

• Explore support for abi3t ABI tag #1252, closed by feat: support PEP 803, free-threaded tag #1269
• Add PEP 803 support pypa/pip#13879, closed after pip vendored packaging with PEP 803 support
• several project-side tracker issues for publishing abi3t wheels, such as Tracker: publishing cp315-abi3.abi3t wheels neutrinoceros/rlic#436 and Upload cp314t and eventually abi3.abi3t wheels pola-rs/polars#27955

I did not find an existing scikit-build-core issue for the specific behavior below.

Reproducer

I tested scikit-build-core main at commit e4fe16c5a1206bd025424c195f7c383da6264080 on CPython 3.15.0b3 free-threaded:

scikit-build-core 0.12.3.dev89+ge4fe16c5a
cmake 4.3.4
pip 26.1.2
packaging 26.2
Python 3.15.0b3 free-threading build

Build command:

python -m pip wheel . -w /tmp/wheelhouse --no-deps --no-build-isolation \
  --config-settings=wheel.py-api=cp315t \
  --config-settings=cmake.args="-DAISCAT_ABI3T=ON;-DCMAKE_BUILD_TYPE=Release"

Generated wheel:

aiscat-0.68.14-cp315t-abi3t-linux_x86_64.whl
Tag: cp315t-abi3t-linux_x86_64
contains: aiscat/_core.abi3t.so

Install result on the same interpreter:

ERROR: aiscat-0.68.14-cp315t-abi3t-linux_x86_64.whl is not a supported wheel on this platform.

On that interpreter, packaging.tags.sys_tags() includes cp315-abi3t-* tags, but does not include cp315t-abi3t-*.

Tag compatibility question

As I understand PEP 803 and the current pip/packaging behavior, installer-compatible abi3t wheel tags use a GIL-independent Python tag such as cp315, with the free-threaded stable ABI represented in the ABI tag:

cp315-abi3t-*
cp315-abi3.abi3t-*

Current pip/packaging does not accept:

cp315t-abi3t-*

So this may be a mismatch between scikit-build-core's current interpretation of wheel.py-api=cp315t and the PEP 803 / installer-compatible wheel tag set.

Why this looks like a release blocker

scikit-build-core main currently documents wheel.py-api=cp315t and its tests appear to expect cp315t-abi3t-*:

tags = WheelTag.compute_best(["x86_64"], py_api="cp315t")
assert str(tags) == "cp315t-abi3t-macosx_10_10_x86_64"

But current pip/packaging does not consider that tag compatible. This means projects cannot install the produced wheel without retagging it.

For comparison, when I retagged the same wheel to a pip-compatible abi3t tag, the extension installed and ran correctly; the contained extension was already aiscat/_core.abi3t.so.

The C extension side appears to be past the relevant CPython 3.15 C API pieces: the extension uses the PEP 793/803-style module export path (PyModExport__core, Py_mod_abi, Py_MOD_GIL_NOT_USED) and produces an .abi3t.so. The remaining issue appears to be the wheel tag, not the compiled extension.

Could you confirm whether scikit-build-core should keep cp315t only as the user-facing build selector, but emit an installer-compatible wheel tag such as cp315-abi3t-* or cp315-abi3.abi3t-*? Or is cp315t-abi3t-* intended to become accepted by packaging/pip later?

Once the emitted tag is aligned with installers, it would be very helpful to publish a new PyPI release so projects can test abi3t wheels without depending on a git checkout or manual retagging.

[honglei]

One additional API design thought after reviewing the tag semantics:

It seems useful to separate the user-facing build selector from the emitted wheel tag.

For example, if a project does not request the Stable ABI / limited API, a free-threaded 3.15 build should remain a normal interpreter-specific wheel, e.g.:

cp315-cp315t-*

If a project explicitly requests the free-threaded Stable ABI, wheel.py-api="cp315t" could remain the user-facing selector, but emit an installer-compatible abi3t-only wheel tag, e.g.:

cp315-abi3t-*

The combined GIL + free-threaded Stable ABI case seems like a stronger compatibility claim and probably needs an explicit opt-in from the project, rather than being inferred automatically. One possible future interface could be something like:

wheel.py-api = "cp315"
wheel.abi-tags = ["abi3", "abi3t"]

which would emit:

cp315-abi3.abi3t-*

The exact setting name is not important here; the main point is that abi3t-only and combined abi3.abi3t wheels are different compatibility claims, and projects likely need a clear way to choose between them.

[henryiii]

Thanks! Yes, I believe that's a mistake.

Re: dual tags, I intended for this to be possible: wheel.py-api = "cp313.cp315t" should work (but it doesn't). I'm fixing the mistake first, then will look into that.