chore(deps): drop unused twine pin from requirements-testing.txt

[crowecawcaw]

What was the problem/requirement? (What/Why)

#1314 (dependabot) bumps twine == 6.* → 7.* in requirements-testing.txt. That PR's CI is red: twine 7.0.0 raised its floor to Python >= 3.10 (6.0.0 was >=3.8, 6.2.0 >=3.9), and requirements-testing.txt is installed on every leg of the 3.9–3.14 matrix in code_quality.yml:

ERROR: Ignored the following versions that require a different python version: ... 7.0.0 Requires-Python >=3.10
ERROR: No matching distribution found for twine==7.*

(Only the ubuntu-latest, 3.9 job actually failed there — the other 17 were cancelled by fail-fast.)

Adding a ; python_version >= '3.10' marker would go green, but it papers over the real issue: twine does not belong in requirements-testing.txt. Nothing under test/ or scripts/ imports it. It was being installed into all 18 matrix jobs and never invoked by any of them.

The pin was also inert where twine actually runs. pipeline/build.sh and pipeline/build.ps1 do pip install --upgrade twine before pipeline/publish.sh calls twine upload, so the publish path already resolved whatever the latest twine was, regardless of the == 6.* pin.

What was the solution? (How)

Delete the twine line from requirements-testing.txt. That's the whole change — one line.

This removes twine from all 18 CI matrix jobs and closes out #1314's intent (the publish path picks up twine 7 via the existing --upgrade, as it always has). The pipeline/ scripts are deliberately left alone.

On "do we need more than one Python version to release?" — no

The deadline wheel is universal (py3-none-any, confirmed by both the current PyPI artifact and hatch build locally), so publishing only ever runs on a single interpreter:

Path	Interpreter	Uses twine?
manual_pypi_release.yml	3.13	No — pypa/gh-action-pypi-publish
release_publish.yml	build-python-version from reusable_tag_release.yml	No — same action
Internal CodeArtifact (pipeline/publish.sh)	AL2 standard 5.0 CodeBuild image	Yes

I checked the internal CDK package that owns the CodeArtifact publish project: its Python constants are 3.13.14 for Linux/Windows/macOS, and the publish CodeBuild project uses LinuxBuildImage.AMAZON_LINUX_2_5. Both are comfortably above twine 7's 3.10 floor, so the --upgrade twine in the publish path resolves fine.

The 3.9–3.14 matrix is runtime test coverage for the library; it is not build or publish coverage. twine never needed to run on 3.9.

What is the impact of this change?

Removes a never-used dependency from 18 CI jobs. No change to the shipped package, to any runtime code path, or to the publish scripts.

How was this change tested?

Locally on Python 3.14, matching the three steps the CI matrix runs (reusable_python_build.yml):

• hatch -v run lint — clean (ruff check, ruff format, mypy: no issues in 314 source files)
• hatch -v build — clean; produced deadline-...-py3-none-any.whl + sdist, confirming the universal-wheel claim above
• hatch run test — 3158 passed, 21 skipped; coverage 77.55% (gate 69%)

Also verified in a clean venv that requirements-testing.txt resolves with no twine present, and that twine 7.0.0 installs and runs (twine --version) on Python 3.14.

I have not exercised the internal CodeArtifact publish path end-to-end — that only runs in the internal pipeline. Since pipeline/publish.sh is untouched and already did --upgrade twine, its behaviour is unchanged by this PR.

Was this change documented?

No user-facing change; no docs or changelog entry needed.

Is this a breaking change?

No.

---

This should supersede #1314 — worth closing that one if this merges. If the team would rather keep dependabot tracking twine here, the minimal alternative is twine == 7.*; python_version >= '3.10' in requirements-testing.txt; happy to close this in favour of that instead.

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.