feat(TRI-1118): add --release-version + PEP 440/817 wheel scheme#503
Draft
mc-nv wants to merge 6 commits into
Draft
feat(TRI-1118): add --release-version + PEP 440/817 wheel scheme#503mc-nv wants to merge 6 commits into
mc-nv wants to merge 6 commits into
Conversation
Adds a --release-version CLI flag with a TRITON_RELEASE_VERSION env-var
fallback to build_wheel.py. Precedence: CLI flag > env var >
in-tree TRITON_VERSION file. CI can now pin a release tag without
editing the source-tree TRITON_VERSION.
Classifies the base version by regex:
- X.Y.Z (release-semantic) -> PEP 440 normalized output: no PEP 440
local segment, no PEP 427 build tag, no variant label. PyPI-clean.
- anything else (.devN, aN, rcN, etc.) -> PEP 817 variant: keeps the
PEP 427 build tag (CI_PIPELINE_ID) and appends a PEP 817 variant
label (nv<container>.cu<major><minor>) to the wheel filename after
the platform tag. Backward-compatible -- pre-PEP 817 installers
ignore variants and fall back to a non-variant wheel.
ANSI-colored info lines surface the chosen path in CI logs.
Refs TRI-1118.
…EP 427 build tag
Pre-this-commit, dev wheels carried the CI pipeline id as a PEP 427
build tag between version and python-tag:
tritonserver-2.70.0.dev0-12345-cp310-cp310-...-nv26.05.cu132.whl
PEP 427 build tags are rejected by public PyPI and duplicate the
identity that already belongs in the version string.
Switch to PEP 440 .dev<N> counter semantics. When the resolved base
version matches X.Y.Z.devN and CI_PIPELINE_ID is a positive integer,
replace the dev counter with the pipeline id:
2.70.0.dev0 + CI_PIPELINE_ID=12345 -> 2.70.0.dev12345
Resulting filename:
tritonserver-2.70.0.dev12345-cp310-cp310-...-nv26.05.cu132.whl
This is PyPI-uploadable, PEP 440-sortable across reruns
(dev12346 > dev12345), and removes the need for any PEP 427 build-tag
injection in `python -m build`.
The PEP 817 variant label path is untouched: dev versions still
classify as non-release and get the nv/cu label appended. Release
wheels (X.Y.Z) remain PyPI-clean. Local dev builds without
CI_PIPELINE_ID keep their in-tree .dev0.
Refs TRI-1118.
Two related fixes for the wheel-build / install pipeline:
1) auditwheel manylinux wheel was never installed.
_repair_wheel_with_auditwheel() was passing --wheel-dir=<dest_dir>,
which writes the manylinux wheel one directory above where the
CMake `install(DIRECTORY ${WHEEL_OUT_DIR})` line reads from
(<dest>/wheel/dist/). Result: the manylinux wheel was produced but
never copied to /opt/tritonserver/python/ in the base image -- the
publish job uploaded only the pre-repair linux_<arch> wheel.
Switch --wheel-dir to dist_dir so auditwheel writes alongside the
pre-repair wheel; on success, remove the original linux_<arch>
wheel so dist_dir carries a single canonical manylinux artifact.
2) Dev-counter rewrite didn't match the in-tree TRITON_VERSION.
The previous regex required canonical PEP 440 X.Y.Z.devN; in-tree
`TRITON_VERSION` files use the legacy `X.Y.Zdev` shape (no period,
no counter). Relax to ^(\d+\.\d+\.\d+)\.?dev\d*$ so both forms
match and CI_PIPELINE_ID gets substituted as the dev counter.
Refs TRI-1118.
…o .so
Previous logic hardcoded `manylinux_2_28_<arch>` for any wheel auditwheel
reported as "no ELF". Result: pure-Python wheels (e.g. downstream builds
that disabled bindings) carried a false manylinux compatibility promise.
New routing inspects the wheel zip for native `.so` members up front:
Has `.so` -> auditwheel repair. auditwheel chooses the lowest
`manylinux_<X>_<Y>_<arch>` policy that covers the .so's
glibc symbol requirements, per PEP 513 / PEP 599 / PEP 600.
Original `linux_<arch>` wheel is removed on success.
No `.so` -> `python -m wheel tags --python-tag py3 --abi-tag none
--platform-tag any --remove` -> emit a canonical
`py3-none-any` pure-Python wheel per PEP 425. The
manylinux tag is OMITTED -- claiming manylinux on a wheel
with no glibc-bound code would be a false promise.
PEP 656 musllinux is not produced here (build containers are glibc-based;
auditwheel-musl would be needed on musl distros). PEP 440 version
normalization still happens upstream of this function in the dev-counter
rewrite.
Add `_wheel_has_so()` helper using zipfile + basename inspection
(matches `*.so` and `*.so.<ver>`), the same classification heuristic
auditwheel and pip use.
Refs TRI-1118.
Symptom (job 342953964 / pipeline 55073480):
tritonserver-2.70.0-cp312-cp312-manylinux_2_27_x86_64.manylinux_2_28_x86_64.whl
tritonserver-2.70.0-cp312-cp312-manylinux_2_26_aarch64.manylinux_2_28_aarch64.whl
Cause: CMake's add_custom_command for the wheel target runs twice
(build phase + install phase). The first run produces a manylinux wheel
in `wheel/dist/` and removes the linux_<arch> input. The second run's
`python -m build` re-creates the linux_<arch> wheel; dist/ now contains
both. _repair_wheel_with_auditwheel iterates over `os.listdir(dist_dir)`
and invokes auditwheel on each, including the already-manylinux leftover.
auditwheel applied to an already-tagged wheel emits a compressed PEP 425
tag set (e.g. manylinux_2_27_x86_64.manylinux_2_28_x86_64) -- valid but
noisy.
Two-belt fix:
1. Clean wheel/dist/ before `python -m build` runs so leftovers from
a previous CMake pass can't accumulate.
2. In _repair_wheel_with_auditwheel, skip wheels whose filename
already carries a manylinux or musllinux tag (defensive guard for
any other source of stale wheels).
Together these make the script idempotent across repeated CMake
invocations and ensure each wheel carries exactly one platform tag.
Refs TRI-1118.
…sion If auditwheel emits (or has emitted) a wheel whose PEP 425 platform-tag component is a compressed set of manylinux entries -- e.g. manylinux_2_27_x86_64.manylinux_2_28_x86_64 -- collapse to the highest version (manylinux_2_28_x86_64). The lower-version entry is redundant (higher version is the strictest applicable glibc baseline, aligned with the build container's manylinux policy). Implementation: scan dist/ after _repair_wheel_with_auditwheel completes; parse each wheel filename; if the platform-tag component contains multiple manylinux_X_Y_<arch> entries, sort by (X, Y) and rewrite the tag via `python -m wheel tags --platform-tag <highest> --remove`. Single-tag wheels and pure-Python (py3-none-any) wheels are no-ops. Non-manylinux entries in a compressed set (rare) are preserved. Refs TRI-1118.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does the PR do?
Adds a
--release-versionCLI flag with aTRITON_RELEASE_VERSIONenv-var fallback topython/build_wheel.py. Precedence: CLI flag > env var > in-treeTRITON_VERSIONfile. CI can pin a release tag without editing the source-treeTRITON_VERSION.The base version is classified by regex:
X.Y.Z(release-semantic) → PEP 440 normalized output (no local segment, no PEP 427 build tag, no variant label). PyPI-clean..devN,aN,rcN,.postN, …) → PEP 817 variant: keeps the PEP 427 build tag and appends a PEP 817 variant labelnv<container>.cu<major><minor>to the wheel filename after the platform tag. Backward-compatible — pre-PEP 817 installers ignore variants and fall back to a non-variant wheel.ANSI-colored info lines surface the chosen path in CI logs.
Checklist
<commit_type>: <Title>Commit Type:
Related PRs:
triton-inference-server/server#8845
Where should the reviewer start?
python/build_wheel.py— the_compose_variant_labelhelper plus the inline release/variant decision in__main__.Test plan:
Helper unit-test (no Docker): exercise
_compose_variant_labeland the version classifier with the matrix in TRI-1118 (release vs dev/pre-release vs garbage).Filename rename simulation: synthesize a fake
*.whl, run the rename loop, confirm shape…-{platform}-nv<container>.cu<XYZ>.whl.Container build with
--release-version 2.70.0→ wheel filename istritonserver-2.70.0-...whl(PyPI-clean).Container build with
--release-version 2.70.0.dev0→ wheel filename includes-nv<container>.cu<XYZ>variant label.L0_* tests pass with no new failures.
CI Pipeline ID:
Caveats:
variant.jsonmetadata inside the wheel. When mainstream PEP 817 tooling lands, these wheels may need a follow-up to add the metadata.Background
Part of TRI-1118 (CI artifactory publishing). The PEP 440 local-version segment (
+nv26.05.cu132) is rejected by PyPI uploads, blocking artifactory publishing. This change moves the disambiguation into a separate filename slot via PEP 817.Related Issues: