[jaraco]

Summary of changes

Refreshes the vendored packaging from 26.0 to 26.3 and raises its declared floor to match, following the precedent of 8e13abf ("Update vendored packaging version to 24.2"), which bumped both the test and core extras alongside the vendored copy.

Why

packaging 26.3 adds the abi3t tag from PEP 803 (pypa/packaging#1099). The vendored 26.0 cannot emit it — its _abi3_applies(python_version, threading) returns False for free-threaded builds, so tags.sys_tags() yields neither abi3 nor abi3t there.

That blocks #5193, whose supported-tag assertion is:

assert any(t in supported_tags for t in possible_tags), (
    f"would build wheel with unsupported tag {tag}"
)

With 26.0 on a free-threaded 3.15 that can never hold, because no abi3-family tag is ever offered. #5256 does not address this — it keeps packaging-26.0 and only rewrites that dist-info.

Verified against the newly vendored copy:

vendored packaging: 26.3
has _abi3t_applies: True
abi3t tags for 3.15: ['cp315-abi3t-linux_x86_64', 'cp315-abi3-linux_x86_64', ...]

Method

Scoped to this one dependency rather than re-vendoring everything, using the technique from tools/vendored.py — remove the existing copy, then uv pip install --target setuptools/_vendor --python-version <requires-python floor> --only-binary :all:. packaging declares no runtime dependencies, so nothing else under _vendor moves; git status on that directory shows only packaging* paths.

Testing

• Full suite (excluding integration): 991 passed, 15 skipped, 17 xfailed, 3 xpassed.
• 26.0 → 26.3 is a larger diff than the version numbers suggest: it adds _ranges.py, ranges.py, dependency_groups.py, direct_url.py and errors.py, and substantially rewrites version.py, tags.py and utils.py. The full-suite run above is the main guard against regressions in metadata, requirements and version handling.

Two things to flag

The check-changed-folders job will fail, by design — it fails on any PR touching setuptools/_vendor/** as a tripwire against hand-editing vendored code. #5256 shows the same failure. Nothing in .mergify.yml gates on it.

A LICENSE file nearly went missing. packaging-26.3.dist-info/licenses/LICENSE had to be git add -f'd: a bare LICENSE pattern in a global gitignore matches it at any depth, git status then reports the tree clean, and the previously tracked packaging-26.0.dist-info/licenses/LICENSE would have been silently dropped. All three license files (LICENSE, LICENSE.APACHE, LICENSE.BSD) are present here and match the hashes in RECORD. Worth knowing for future tox -e vendor runs, and relevant to #5049, #5215 and #5001; a !LICENSE negation in the repo's own .gitignore would make this safe by default.

Pull Request Checklist

• Changes have tests (covered by the existing suite; vendored code is not separately tested)
• News fragment added in newsfragments/. (See documentation for details)

🤖 Generated with Claude Code