fix: include legacy manylinux aliases in --platform tags

[BrandonLWhite]

Problem

poetry bundle venv --platform manylinux_2_34_aarch64 cannot install a wheel whose only Linux tag is a legacy manylinux alias, even though PEP 600 defines manylinux2014_aarch64 as an alias for manylinux_2_17_aarch64, which a glibc 2.34 target satisfies.

For example, duckdb-extension-httpfs 1.5.5 ships its aarch64 build only as py3-none-manylinux2014_aarch64, so bundling a project that depends on it fails:

Unable to find installation candidates for duckdb-extension-httpfs (1.5.5)

Asking for the legacy platform explicitly fails the same way: --platform manylinux2014_aarch64 also rejects a manylinux2014_aarch64 wheel.

Root cause

create_supported_manylinux_platforms normalizes the --platform value through LEGACY_MANYLINUX_ALIASES, then emits only PEP 600 spellings: manylinux_2_{N}_{arch} for every N from the requested glibc minor down to 0. Poetry's chooser matches wheel tags against env.supported_tags by exact string, so a wheel tagged only with an alias never matches.

PEP 600's reference code applies its alias table to the wheel's tag before comparing. The plugin applied it only to the requested platform.

This went unnoticed because most wheels carry both spellings, for example manylinux_2_17_x86_64.manylinux2014_x86_64. Every wheel in the existing project_with_binary_wheel fixture is dual-tagged.

Fix

Emit each legacy alias right after the PEP 600 tag for the same glibc version:

• manylinux_2_17 → manylinux2014
• manylinux_2_12 → manylinux2010
• manylinux_2_5 → manylinux1

The alias lookup is the existing LEGACY_MANYLINUX_ALIASES map, inverted.

The order matters. Poetry's chooser ranks compatible wheels of the same version by their earliest index in supported_tags. A wheel built for a newer glibc still wins, and at the same glibc version the alias ranks just below the PEP 600 spelling.

Aliases are emitted for every architecture, matching how the existing input normalization treats them. An alias that PEP 600 does not define for an architecture, such as manylinux1_aarch64, matches no wheel, just as the existing manylinux_2_0_aarch64 tag matches none today.

Precedent

• packaging, which Poetry uses for the host's own tags: packaging._manylinux.platform_tags yields each legacy alias immediately after the PEP 600 tag for the same glibc version. On an aarch64 host with glibc 2.34, its list ends manylinux_2_18_aarch64, manylinux_2_17_aarch64, manylinux2014_aarch64. So Poetry running on the target host itself would install the httpfs wheel above, and this change makes --platform agree with it.
• uv: uv pip install --python-platform aarch64-manylinux_2_34 duckdb-extension-httpfs==1.5.5 installs the manylinux2014_aarch64 wheel (tested with uv 0.12.17). Its tag generator (crates/uv-platform-tags/src/tags.rs) pushes manylinux2014 right after manylinux_2_17, commented "Support legacy manylinux tags with lower priority" and citing PEP 600.
• pip: pip download --platform (26.2.1) matches only the exact tags passed, with no downward glibc expansion and no aliases, so it cannot fetch even a manylinux_2_28 wheel for --platform manylinux_2_34_aarch64. That is tracked as a bug in pip doesn't handle PEP600 compatible manylinux wheels when --platform is specified. pypa/pip#10760 (open since 2022; maintainers said they would accept a fix), not as intended behavior.

Verification

• Unit: 28/28 tests pass, mypy is clean, and all pre-commit hooks pass.
  • Tests were written first, and all three failed before the fix because the alias tags were missing:
    • test_create_supported_tags_manylinux_includes_legacy_aliases (new): for manylinux_2_34_aarch64, the manylinux2014_aarch64 alias is present for the cp314, abi3 and py3 tags.
    • test_create_supported_tags_ranks_legacy_alias_with_its_glibc_version (new): manylinux2014_aarch64 sits directly between manylinux_2_17_aarch64 and manylinux_2_16_aarch64.
    • test_create_supported_tags_legacy_manylinux_aliases (extended): the aliases at or below the requested glibc version are present, and newer ones are not. For example, manylinux2010_x86_64 does not yield manylinux2014_x86_64.
• End to end: I ran a real poetry bundle venv --without dev --platform manylinux_2_34_aarch64 on an x86_64 host, for a Python 3.14 project that depends on duckdb==1.5.5 and duckdb-extension-httpfs==1.5.5.
  • With this change (Poetry 2.5.0), the bundle succeeds. It installs duckdb's manylinux_2_26_aarch64.manylinux_2_28_aarch64 wheel and httpfs's manylinux2014_aarch64 wheel, whose extension binary is an aarch64 ELF.
  • With 1.8.0 (Poetry 2.5.1), the same command fails with Unable to find installation candidates for duckdb-extension-httpfs (1.5.5).

🤖 Generated with Claude Code