Conversation
| # pytorch/.ci/aarch64_linux/aarch64_wheel_ci_build.py for this logic. | ||
| build_date=$(cd "$PYTORCH_LOCAL_DIR" && git log --pretty=format:%cs -1 | tr -d '-') | ||
| # NOTE: This relies on the fact that we only ever perform a shallow clone of the | ||
| # PyTorch repo so the first commit is the latest commit on the branch we clone, |
There was a problem hiding this comment.
This fix is fine for a docker build, but if you're using TS as a local dev environment, you're at risk of some unexpected version suffixes?
There was a problem hiding this comment.
That's a tricky one! Perhaps we could cheat and override the date when we apply the patches instead?
There was a problem hiding this comment.
I think we need to consider moving these hash values into a separate e.g. versions.sh and source that file in any shell script that needs it. It's better than forcing scripts to pass values between each other
There was a problem hiding this comment.
See optional replacement PR here. Requires more changes but handles things in a cleaner way. Have been meaning to make this change for a while...
puneetmatharu
force-pushed
the
patch-torch-wheel-naming
branch
from
8924dd3 to
b1a0c01
Compare
3 participants
Previously we got the date of the last patch in the PyTorch repo (and thus the version number for the
torchwheel) from the date of the last commit in the repo. This worked fine when we left applied patches unstaged. However, after we updatedapply-github-patchto actually make commits from each patch, we can't rely on this logic anymore. I've updated the implementation to rely on the date of the first commit on that branch (since we do a shallow clone of the repo) which will match the commit we did a shallow clone on.I've also updated
CHANGELOG.mdaccordingly.Important
This PR is superseded by #439. Only one of these two PRs should be merged in.