bc36d7d6c8
The relative exclude-newer = "14 days" cutoff bricks installs whenever the resolver cannot see (or accept) a package's upload date: - defusedxml / python-olm / unpaddedbase64 (#80387, #79434): ancient frozen releases (2021-2023) whose upload dates are often absent from mirror indexes and stale uv HTTP caches. uv then filters them entirely ("there are no versions of defusedxml"), breaking [youtube]/[wecom]/ [matrix] resolution and daily `uv sync --locked` runs. - setuptools / pillow / mcp (#78227, #75992, #76020): exact-pinned deps. When the pinned version's upload date is invisible, the resolver filters the ONLY acceptable candidate — setuptools==83.0.0 in [build-system].requires meant the project could not even be built from a git checkout on released v0.20.0. Exempting an exact pin costs nothing: the version cannot float without a reviewed pin bump. Changes: - pyproject.toml: add all six to the existing exclude-newer-package whitelist, with rationale comments per class. - uv.lock: regenerated; diff is the whitelist metadata only (verified zero version drift, still 249 packages). - tests/test_packaging_metadata.py: new standing guard test_build_system_requires_exempt_from_exclude_newer — every [build-system].requires package must be whitelisted while a relative exclude-newer cutoff is configured. Verified both directions (fails when setuptools is removed from the whitelist). - scripts/install.sh: fix the stale tier-name comparison ("all (with RL/matrix extras)" vs actual "all") that mislabeled every successful Tier-1 install as a fallback-tier install (#79434 bonus finding). Verification: uv lock --check green on uv 0.11.19 and 0.12.5; uv sync --extra all --locked green; uv pip install -e '.[all]' resolves; whitelist mechanism A/B-proven on a minimal project (unsatisfiable -> resolves; build-requires variant: uv build fails -> succeeds). Reported-by: MichaelClawHub (#80387), liujianqiu (#79434), maxonliu (#78227)