Add git SHA to wheel versions using versioningit

[janbernloehr]

Adds automatic git SHA suffixing to wheel versions during development builds, matching the behavior of other PyTorch libraries (e.g., pytorch/ao).

Changes:

• Configured versioningit for automatic version generation from git tags
• Development builds now generate versions like: 0.2.0+gitf5e3a84e
• Tagged releases remain clean: 0.2.0

For releases: Versions are automatically determined from git tags (e.g., v0.2.0).

Build system: Adds versioningit>=3.3 to build requirements. No runtime dependencies added.

[meta-cla[bot]]

Hi @janbernloehr!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at [email protected]. Thanks!

[meta-cla[bot]]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks!

[janbernloehr]

• a comparison on what's the before & after behavior? Specifically what's the benefit?

The before behavior is: if you build a wheel of torchtitan it will get the version of version.txt - irregardless of how many changes have been done. This makes it hard to distinguish development builds from release builds. The after behavior is: Only when building on the commit of a tag, we get the version from the tag, e.g. v0.2.0. In all other cases, the version is derived by setuptools, e.g. 0.2.0.post77+gf5e3a84e (77 commits after v0.2.0 tag)

• what's the full flow of doing a release after this change. Possibly also update https://github.com/pytorch/torchtitan/blob/main/docs/release.md?

done

We can also choose a different mechanism to derive the version number. I chose setuptools_scm because it is somewhat standard and works well with the pyproject.toml. but e.g. pytorch, ao, and vision use a setup.py to compute the version and also get slightly different version suffixes (e.g. on 2.0.0 and commit b425c6f) one would get:

• torch: 2.0.0+gitb425c6f
• ao: 2.0.0+gitb425c6f
• vision: 2.0.0+b425c6f

[fegin]

Thanks for the PR. I feel we can remove .github/scripts/update_version.sh and just use importlib.metadata to get the version. But this is orthogonal to this PR.

[tianyu-l]

I feel we can remove .github/scripts/update_version.sh and just use importlib.metadata to get the version. But this is orthogonal to this PR.

so context is that update_version.sh is for producing nightly. So not sure if / how it can be saved. @joecummings who added the file may know how.

[fegin]

If one install TorchTitan package correctly, the version should be in metadata. And since this PR make version to be dynamic, it will automatically reflect the latest version with git SHA.

[joecummings]

Removing the version.txt file will break any builds intending to use the PyTorch Dev Infra build system and since this isn't urgent, I'd like to not merge quite yet.

I know there's been changes to how Dev Infra wants to continue these workflows so let me get @seemethere's thoughts as well. Will update on this thread by EOD today.

[joecummings]

Removing the version.txt file will break any builds intending to use the PyTorch Dev Infra build system and since this isn't urgent, I'd like to not merge quite yet.

I know there's been changes to how Dev Infra wants to continue these workflows so let me get @seemethere's thoughts as well. Will update on this thread by EOD today.

@atalman It looks like we could pass in an override to the nightly package here. Am I understanding correctly? If so, does it make sense to bubble up to the top level build script?

I'm also curious in general if continuing to hack on these Nova workflows is the right way to go to do these nightly builds?

[wwwjn]

Removing the version.txt file will break any builds intending to use the PyTorch Dev Infra build system and since this isn't urgent, I'd like to not merge quite yet. I know there's been changes to how Dev Infra wants to continue these workflows so let me get @seemethere's thoughts as well. Will update on this thread by EOD today.

@atalman It looks like we could pass in an override to the nightly package here. Am I understanding correctly? If so, does it make sense to bubble up to the top level build script?

I'm also curious in general if continuing to hack on these Nova workflows is the right way to go to do these nightly builds?

@joecummings @atalman do we have conclusion whether this change looks good for Forge side?