[shoumikhin]

What is wrong today

A published wheel's executorch extra requires the delegate package, torch-tensorrt-executorch-runtime, and the delegate pins one exact ExecuTorch build. If the wheel's index lacks either, pip does not fail. It quietly installs another torch-tensorrt without the delegate.

What this change does

1. The extra requires the delegate only where its ExecuTorch build is published:

   • a nightly whose pin is an ExecuTorch nightly,
   • a release candidate whose pin is an ExecuTorch release,
   • a Linux PyPI wheel whose pin is an ExecuTorch release.

   For 2.15 on Linux, PyPI gets the CUDA 13.2 builds of PyTorch and ExecuTorch, so it must get the cu132 Torch-TensorRT and delegate wheels too, or one install mixes CUDA versions. The release workflows still build cu132 and cu134; the release checklist says to upload the cu132 wheels to PyPI. PyPI's Windows ExecuTorch is a CPU build, so the Windows PyPI wheel leaves the delegate out and builds none.

2. The error messages name the installed version, the recorded delegate, and indexes that have both: the nightly index for a nightly, the test index for a release candidate, and the stable index for a PyPI release.

3. Build jobs also search the test index for a release pin.

4. The guide shows one install command per channel, and the runtime README links to it.

Docs describe the end state; still needed

• ExecuTorch's CUDA 13.2 build on PyPI for Linux. Stage the CUDA build of ExecuTorch for PyPI on Linux test-infra#9171 stages it from a CUDA index, and Stage ExecuTorch's PyPI wheels from the test channel's CUDA version, like torch test-infra#9215 makes that index cu132, like Add torch to release-stage-pypi workflow test-infra#9195 for torch.
• ExecuTorch's Windows CUDA release wheels on the test index, or the Windows release candidate cannot build its delegate.
• For the nightly command, the nightly index has to carry dllist, TensorRT and about a dozen ExecuTorch dependencies (s3_management: mirror torch_tensorrt[executorch] dependencies to the cu132 and cu134 indexes test-infra#9196), and torchao for Windows. Until then it also needs --extra-index-url https://pypi.org/simple, and on Windows the CPU nightly index.

What was tested

• Unit tests run the real setup.py blocks, workflow steps and release matrix script. Each changed check fails a test when reverted. Only the nightly case runs in pull request CI.
• Linux aarch64: the published nightly (built before this change) installed matching nightlies, and a small model ran through the delegate and matched PyTorch.
• With stand-in wheels on local indexes, the command resolves to torch-tensorrt 2.15.0, delegate 0.2.1 and ExecuTorch 1.6.0.
• Not tested: a real release, and Windows.

[shoumikhin]

@lanluo-nvidia @narendasan could you take a look when you have a moment?

[lanluo-nvidia]

our generate-release-matrix.py is for generate the one for both pypi and github release stuff, so it is for both cu132 and cu134, and for pypi we upload cu134, for github release we upload both cu132 and cu134

[shoumikhin]

Thanks, you are right: the script feeds more than PyPI, so it should not drop cu134. I put the matrix back, so the release workflows build cu132 and cu134 again, as they do on main. I will make the same change in #4909.

What I would change is which build goes to PyPI. A plain pip install "torch_tensorrt[executorch]" takes torch and executorch from PyPI. For 2.15, torch there will be the CUDA 13.2 build (pytorch/test-infra#9195), and pytorch/test-infra#9215 stages ExecuTorch's CUDA 13.2 build the same way. If Torch-TensorRT and the delegate on PyPI are cu134, one install mixes CUDA 13.2 and 13.4. So the release checklist now says to upload the cu132 wheels to PyPI. cu134 users still get cu134 from the PyTorch index.

Does that work for your release process?

[lanluo-nvidia]

lgtm