fix: tag tritonfrontend wheel with arch-specific platform tag (TRI-983)#8761
Open
fix: tag tritonfrontend wheel with arch-specific platform tag (TRI-983)#8761
Conversation
Replace the legacy bdist_wheel.get_tag() override that hard-coded py3-none-any with BinaryDistribution.has_ext_modules()=True, mirroring the fix applied to the tritonserver wheel in core/. Add _repair_wheel_with_auditwheel() to build_wheel.py so the wheel is upgraded from linux_<arch> to manylinux_2_X_<arch> for PyPI compatibility. The container image still receives the linux_<arch> wheel from generic/wheel/dist/ (correct for in-container pip install); the manylinux wheel is written to generic/ for future PyPI publishing. Also replace the deprecated distutils.dir_util.copy_tree with shutil.copytree (symlinks=True, dirs_exist_ok=True).
…983)
Port _detect_cuda_version() and _compose_version() from core/python/
build_wheel.py so the tritonfrontend wheel gets the same
+nv{release}.cu{cudaXY} local-version segment as tritonserver.
Add PEP 427 build-tag sourcing (CI_PIPELINE_ID / NVIDIA_BUILD_ID /
BUILD_NUMBER) passed as --build-number=<N> to setup.py bdist_wheel,
mirroring the logic in core/python/build_wheel.py.
build_wheel.py prefers CI_PIPELINE_ID over NVIDIA_BUILD_ID as the PEP 427 wheel build tag, but CI_PIPELINE_ID was never forwarded into the build container. NVIDIA_BUILD_ID is baked in as ENV from build.py --build-id, so add the same treatment for CI_PIPELINE_ID: read it from the host environment and emit ENV CI_PIPELINE_ID <value> in both the Linux and Windows buildbase Dockerfiles, but only when the variable is non-empty so local builds are unaffected.
…TRI-983)" This reverts commit 19b5712.
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
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?
Fix
tritonfrontendPython wheel so it ships with a correct architecture-specificplatform tag instead of
py3-none-any.The root cause was a
bdist_wheel.get_tag()override insrc/python/setup.pythathard-coded
py3-none-anywhen--plat-namewas not passed (which it never was).Changes:
src/python/setup.py— replace thebdist_wheel+get_tag()override withBinaryDistribution.has_ext_modules()=True, mirroring the fix applied totritonserverintriton-inference-server/core. Setuptools now auto-derives thecorrect
cpXY-cpXY-linux_<arch>tag from the current interpreter.src/python/build_wheel.py— add_repair_wheel_with_auditwheel()(ported fromcore/python/build_wheel.py) to upgrade the wheel tomanylinux_2_X_<arch>forPyPI compatibility; add
_detect_cuda_version()and_compose_version()for the+nv{release}.cu{cudaXY}local-version segment; add PEP 427 build-tag sourcing(
CI_PIPELINE_ID→NVIDIA_BUILD_ID→BUILD_NUMBER) passed as--build-number=<N>tosetup.py bdist_wheel; replace deprecateddistutils.dir_util.copy_treewithshutil.copytree.The container image continues to receive the
CI (internal): [#49841381](http://tritonserver.local/ci/pipelines/49841381)linux_<arch>wheel fromgeneric/wheel/dist/; themanylinuxwheel is written togeneric/for future PyPIpublishing.
Resolves: TRI-983
Related: triton-inference-server/core#495
Checklist
<commit_type>: <Title>Commit Type:
Related PRs:
triton-inference-server/core#495
Where should the reviewer start?
src/python/setup.py—BinaryDistributionclass replaces the oldget_tag()override;src/python/build_wheel.py—_repair_wheel_with_auditwheel(),_compose_version(),and the build-tag sourcing block.
Test plan:
Build inside the SDK container (requires
auditwheel— added to Dockerfile.sdk in #8743):Caveats:
PyPI publishing CI jobs (
py3-tritonfrontend-publish) are a follow-up task.Background
Both
tritonserverandtritonfrontendwheels were shippingpy3-none-anydespitecontaining arch-specific
.soextensions — causing Poetry/pip-tools lock file issuesfor users on multi-arch setups. The
tritonserverfix lives intriton-inference-server/core#495.Related Issues: