ci: drop the swig<4.5 build constraint, fixed upstream in PyKCS11 1.5.19

[ihsandeniz]

Closes #1928.

@andersonhc wrote in #1928 that the issue would stay open "until a new version on PyKCS11 is on pypi so we can remove the workaround", and @prateek-dagar reported on 2026-08-27 that the new version was out. This removes the workaround added in #1931.

Why it is safe to remove

PyKCS11 declares requires = ["setuptools", "swig"] in its [build-system], so pip installs swig from PyPI into the build environment — which is why PIP_BUILD_CONSTRAINT worked in the first place. Two independent things changed since #1931:

1. Upstream fixed the build. PyKCS11#167 was closed on 2026-08-24 and released in 1.5.19 (2026-08-26); 1.5.20 followed on 2026-09-04.
2. Linux wheels are published again. 1.5.18 shipped macOS/Windows wheels only, so Linux CI built from the sdist and needed swig at all. 1.5.20 publishes manylinux/musllinux wheels for cp39–cp314, so those jobs no longer compile anything.

Measured, not assumed

Fresh venvs, Python 3.12, swig not installed on the host (so any source build is forced to pull swig from PyPI — currently 4.5.0):

PyKCS11	build constraint	result
1.5.18 sdist	none	❌ error: 'PyInt_FromLong' was not declared in this scope — the exact PyKCS11#167 signature
1.5.18 sdist	swig<4.5	✅ installs — confirms the workaround did its job
1.5.20 sdist	none	✅ installs (also verified with --no-build-isolation against a pinned swig==4.5.0)
1.5.20	(wheel)	✅ pykcs11-1.5.20-cp312-...-manylinux_2_28_x86_64.whl, no compilation

PyKCS11 reaches the CI through endesive, which is in the test extra (endesive → requires_dist: pykcs11). Only the lint and test jobs install .[dev,test], so doc and publish are unaffected.

One subtlety worth flagging

The swig<4.5 line was also the line that created constraints.txt. Deleting it alone would break the test job for every Python version except 3.14, because pip aborts with Could not open requirements file when PIP_BUILD_CONSTRAINT points to a missing path — verified locally. #1931 had removed the previous : > "$CONSTRAINTS_FILE" # create empty file branch for that reason, so this PR restores it. The numpy>=2.3.3 constraint for 3.14 is untouched.

zizmor reports no findings on the modified workflow.

CHANGELOG

Not added, following this repository's own precedent: #1931, which introduced the workaround, has no CHANGELOG entry either, and the CI-related entries that do exist describe user-visible scope changes (adding macOS coverage, enforcing mypy/pyright) rather than temporary build pins. Happy to add one if you would rather have it.

If I have misread anything here, please say so before merging.

[ihsandeniz]

The first run failed on test (3.11, macos-latest) — my mistake, now fixed in 51d8b9de.

It was not the dependency change: the job died on the very first command of the step, before anything was resolved.

Run python -m pip install --upgrade pip setuptools wheel
ERROR: Could not open requirements file: [Errno 2] No such file or directory: 'constraints.txt'

PIP_BUILD_CONSTRAINT is set on the step, so it applies to every pip call in it — including that initial upgrade. The echo 'swig<4.5' > "$PIP_BUILD_CONSTRAINT" line I removed was also the line that created the file, and it ran before that upgrade. I recreated the file but placed it one line too low, so the first pip call still found nothing. Moving : > "$PIP_BUILD_CONSTRAINT" above the upgrade fixes it. The other 14 matrix jobs were cancelled by fail-fast, not failing for a different reason.

Verified locally this time, in the CI's own conditions:

constraints file created	result
after the first pip call (what I pushed first)	❌ Could not open requirements file — reproduces the CI failure
before the first pip call (51d8b9de)	✅ passes

One detail worth recording, since it is what made my first local check pass when it should not have: a fresh venv ships pip 25.x, which ignores PIP_BUILD_CONSTRAINT entirely, so the missing file goes unnoticed. The runners start from a newer pip that does read it. The check is only meaningful after upgrading pip first.

Sorry for the noise on the queue.