Repository navigation
[2.15] Pin ExecuTorch 1.6.0 - #4950
Draft
shoumikhin wants to merge 3 commits into
Draft
shoumikhin wants to merge 3 commits into
shoumikhin wants to merge 3 commits into
Conversation
github-actions
Bot
added
component: tests
This branch pinned the ExecuTorch nightly 1.6.0.dev20261009. The maintainers asked for 2.15 to ship against the ExecuTorch release instead, so this moves the pin to executorch==1.6.0. The move was made with the repository's own updater (write_pins in .github/scripts/update_executorch_pin.py), so every pin site it lists moves together: dev_dep_versions.yml, the two files in packaging/, the MODULE.bazel files, the justfile, the delegate's pyproject.toml and README, and the reference runner README. The source commit pin is ExecuTorch's v1.6.0-rc1 tag (72afc214). The 1.6.0 wheels on PyTorch's test channel are built from that commit, and each one records it in executorch/version.py. If a later release candidate is cut, the pin moves to that commit. 1.6.0 is on the test channel and not yet on PyPI, so it resolves from the test channel until then. The build workflows already install from that channel. uv.lock is refreshed with PYTHON_ONLY=1 uv lock --prerelease=allow. In the lock, executorch moves from 1.6.0.dev20261015+cu132 on the nightly channel to 1.6.0+cu134 on the test channel, the same CUDA 13.4 test channel the lock already takes torch from. hypothesis, kgb and sortedcontainers drop out because the 1.6.0 wheel no longer depends on them. The justfile's install-test-ext also names PyTorch's test index now. A release of ExecuTorch is published there and on PyPI, not on the nightly index, so the nightly index alone cannot find it. The 0.2.1 delegate (torch-tensorrt-executorch-runtime) has to be built against 1.6.0, since it links the runtime from the installed ExecuTorch wheel and its build refuses any ExecuTorch other than the pin.
The test runner's executorch setup step looked for ExecuTorch only on PyTorch's nightly channel. A dated development build lives there, but a release like 1.6.0 is published on the test channel instead, so with the pin on 1.6.0 the step failed with "No matching distribution found for executorch==1.6.0" and the ExecuTorch test suites could not run. The step now names both channels for the row's CUDA version, the same way the build workflows already install the pin. Rows without a CUDA 13 build still get no index, as before. The comment above the step, and the justfile note on running the suite locally, no longer describe the pin as a nightly. The runner test now expects both channels, and it fails if the test channel is dropped again.
Some text still said the pinned ExecuTorch is a nightly build. Now that the pin is the 1.6.0 release, that text is wrong: - the comment on the version range in setup.py said the range admits later nightlies and the release candidate of the pinned minor, and that the floor names a development build because no ExecuTorch release had the runtime the delegate needs - build errors in the delegate's setup.py and CMake file told users to install ExecuTorch from the nightly channel, which does not carry 1.6.0 The comment now says what the range admits from a release floor, and the errors point at the PyTorch CUDA channel that carries the pinned version. No behavior changes.
This branch has not been deployed
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.
Moves the ExecuTorch pin on release/2.15 from the nightly
1.6.0.dev20261009toexecutorch==1.6.0, so 2.15 ships against an ExecuTorch release instead of a nightly.Which build this points at. The source commit pin is ExecuTorch's
v1.6.0-rc1tag (72afc214), the first release candidate. The 1.6.0 wheels on PyTorch's test channel are built from that commit, and each wheel records it inexecutorch/version.py. If ExecuTorch cuts a later release candidate, the pin moves to that commit. The final 1.6.0 keeps the same version string.Where 1.6.0 comes from. 1.6.0 is on PyTorch's test channel (
download.pytorch.org/whl/test/<cuda>), but not on PyPI yet. Until it is on PyPI, the pin resolves from the test channel. The build workflows already install ExecuTorch from there. The nightly channel does not carry releases, so the places that only looked there now name the test channel too (see below).What changed:
write_pinsin.github/scripts/update_executorch_pin.py), sodev_dep_versions.yml, the two files inpackaging/, theMODULE.bazelfiles, the justfile, and the delegate'spyproject.tomland README all agree.uv.lockis refreshed withPYTHON_ONLY=1 uv lock --prerelease=allow. ExecuTorch moves from1.6.0.dev20261015+cu132on the nightly channel to1.6.0+cu134on the test channel, the same CUDA 13.4 channel the lock already takes torch from.hypothesis,kgbandsortedcontainersleave the lock, because the 1.6.0 wheel no longer depends on them.executorchsetup step (tests/ci/runner.py) looked only at the nightly channel, so with the 1.6.0 pin the ExecuTorch test suites could not install it ("No matching distribution found for executorch==1.6.0"). It now names the nightly and test channels, the same way the build workflows do. The justfile'sinstall-test-extnames the test channel as well.torch-tensorrt-executorch-runtime) is built in CI against the installed 1.6.0 wheel. Its build refuses any ExecuTorch other than the pin, so it is rebuilt as part of this change.Tested:
tests/py/dynamo/executorch/test_executorch_pin.pyandtest_update_executorch_pin.pypass.uv lock --check --prerelease=allowpasses on Linux with uv 0.12.5, the version CI uses.72afc214.