feat: support commit hash in package version

[ooooo-create]

What does this PR do ?

Adds commit hash into the package version metadata so built wheels/tarballs encode the exact git revision.

1. uv sync
   

2. uv build
   

3. uv run python -c "import nemo_automodel; print(nemo_automodel.__version__); print(nemo_automodel.__git_version__)"
   

Changelog

• build_backend.py:9-107: new custom build backend that gathers git branch/tag/hash, writes - nemo_automodel/_version.py, and appends the hash to version unless on a release branch or tag; exports git_version.
• __init__.py:16-25: re-exports git_version alongside version and package_name.
• package_info.py:15-16: switches to importing version and git_version from the generated _version.py.
• pyproject.toml:15-33: configures the custom build backend and points the dynamic version source to nemo_automodel._version.version.
• .gitignore:162-164: ignores the generated nemo_automodel/_version.py.
• version.txt:1: sets the base package version to 0.2.0.

Before your PR is "Ready for review"

Pre checks:

• Make sure you read and followed Contributor guidelines
• Did you write any new necessary tests?
• Did you add or update any necessary documentation?

If you haven't finished some of the above items you can still open "Draft" PR.

Additional Information

• Related to CI: version+commit #691

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[Copilot]

Pull request overview

This PR implements commit hash tracking in package versions to enable better traceability of installed packages. The implementation uses a custom build backend that generates version metadata from git information at build time.

Key Changes:

• Introduces a custom build backend (build_backend.py) that wraps setuptools and generates _version.py with git metadata during builds
• Adds version.txt as the single source of truth for the base package version (0.2.0)
• Exports __git_version__ alongside __version__ for runtime inspection of the exact commit

Reviewed changes

Copilot reviewed 6 out of 7 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
build_backend.py	New custom build backend that generates _version.py with git commit hash, branch, and tag information; wraps setuptools build_meta functions
version.txt	New file containing the base package version (0.2.0)
pyproject.toml	Configures custom build backend and updates dynamic version source to use generated _version.py
nemo_automodel/package_info.py	Replaces hardcoded version constants with imports from generated _version.py
nemo_automodel/init.py	Adds git_version to package exports
.gitignore	Excludes generated _version.py from version control
MANIFEST.in	Includes build_backend.py in source distributions

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[akoumpa]

/ok to test 65eb4a1

[akoumpa]

Thanks a lot for the contribution @ooooo-create ,

I want to move this file out of the top-of-tree. Right now I don't see a directory that's 100% suitable, but perhaps the closest would be test/? @thomasdhc please opine on the matter.

[ooooo-create]

Apologies for the delay.
How about we create a _custom_build directory at the project root and move build_backend.py into it? I noticed this pattern in the setuptools documentation.
Additionally, regarding the versioning logic: currently, we rely on branch names (starting with 'release') and git tags to determine whether to exclude the commit hash from the package name. I feel this approach might be a bit brittle.
What do you think about introducing an environment variable, such as AUTOMODEL_VERSION? If this variable is set, the build system should respect it and use it as the definitive version.

[akoumpa]

Hi @ooooo-create , thanks a lot for this.

I'm ok with having a build or build_utils directory and inside contain any util python script that are necessary for building the package.

I'm not 100% sure about introducing an environment variable for the version. I feel that we want to track the version as part of the git repo. The main outcome i want to ensure is achieved is to have the git commit on (a) the package (so that any logs of recipes includes it) and (b) (optionally) to have it on code that was git checkoutd/uv run so that we can have it in the logs there as well (i marked this as optional, since git main refuse to run on shared storage, and in this case it should say n/a instead of failing to run the program completely -- best effort).

@thomasdhc please feel free to take the lead as I feel this falls more on the automation side.

Thanks again @ooooo-create for the contribution, hope you sending more! cheers

[ooooo-create]

Thank you for the clear explanation; I understand the process much better now.
I have implemented support for both scenarios:

1. Regarding wheel packages containing commit info: During the build process, the dynamic_version_info function in build_backend is now called to generate the nemo_automodel/_version.py file. This is used to determine the package name and version.
2. For git checkout and uv run scenarios: I chose to call dynamic_version_info within nemo_automodel/package_info.py to dynamically retrieve and update _version.py. This ensures the version is correct when the package is imported. If git operations fail, it defaults to using gitunknown.
3. Clean versions for PyPI: I added an environment variable NO_GIT_VERSION and a check for git tags. This allows generating package names without the git commit hash, which is more appropriate when publishing to PyPI.