build: lock torch 2.12 and cap <2.13#1
Merged
Merged
Conversation
There was a problem hiding this comment.
Reviewed by Salty Hambot 🤖🧂
Two real traps in a CI-versioning PR: the --upgrade-package "torch<2.9" flag doesn't pin anything (so your 'floor' leg quietly tests whatever's locked), and the whole suite hangs off a private _package import that's liable to vanish mid-range. Fix those and the green checkmark will actually mean something.
2 finding(s) posted.
💬 To request a re-review, comment @salty-hambot review
torch.export / package_pt2 / load_pt2 API is unchanged across 2.8-2.12, so no library changes were needed. Floor stays torch>=2.8 to keep older consumers (e.g. usda-firecon at torch 2.8) resolvable; uv.lock pins the latest released torch (2.12.1) from the pytorch-cpu index.
85555ea to
5be0501
Compare
5be0501 to
64c1d17
Compare
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.
Locks
wherobots-exportagainst the latest released torch (2.12.1) and caps it at<2.13so an untested torch 2.13 can't be pulled in automatically — letting downstream projects (usda-firecon's FireCon pipeline) move off torch 2.8.torch>=2.8,<2.13; adduv.lockresolving torch 2.12.1 from the pytorch-cpu index (wiring up the previously-declared index via[tool.uv.sources]).tests/test_export.pycovering the.pt2export path (save→torch.export→package_pt2) with aload_pt2round-trip and dynamic shapes, plus adevgroup (pytest, numpy).testworkflow running the suite against the locked torch (uv run --frozen).The
torch.export/package_pt2/load_pt2API is unchanged across 2.8–2.12, so no library code changed. The floor staystorch>=2.8so consumers on older torch (e.g. usda-firecon's onboarding at torch 2.8) still resolve; the lock pins the latest.Downstream follow-up (separate usda-firecon PR): usda-firecon tracks this repo's
main; once this lands,uv lock --upgrade-package wherobots-exportthere picks up the new commit, but its onboarding sub-package pinstorchvision==0.23(→ torch 2.8) and needs its own bump to a torchvision paired with the torch it targets (0.25 for 2.10, 0.27 for 2.12).Agent details
save()→.pt2, thenload_pt2()→ExportedProgram.module()reproduces eager output (including a dynamic batch dim that differs from the export-time example).src/— the export API surface is stable across the range.requires-pythonunchanged (==3.12.*).