Automated deployments

[safaricd]

Change Description

Brief (a few bullet points describing your changes, use full sentences and try to link lines in the code whenever needed)

Details (add details if your pull request is more complicated and harder to understand from the code alone)

Standard Qs (leave questions that do not apply blank)

If you broke behavior: Please describe what behavior you broke and how you inform people to not get stuck trying to use the old behavior.

If you used new dependencies: Did you add them to requirements.txt?

Who did you ping on Mattermost to review your PR? Please ping that person again whenever you are ready for another review.

---

Please do not mark comments/conversations as resolved unless you are the assigned reviewer. This helps maintain clarity during the review process.

[gemini-code-assist]

Summary of Changes

Hello @safaricd, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request aims to enhance the project's deployment pipeline by implementing automated versioning. It integrates setuptools-scm to derive version numbers directly from Git, and hatch-vcs to facilitate this process within the build system. This change streamlines releases and ensures consistent versioning across development and deployment.

Highlights

• Automated Versioning Setup: A new _version.py file is introduced, generated by setuptools-scm, to dynamically manage the project's version based on Git tags.
• Dependency Updates for Build System: The uv.lock file has been updated to include hatch-vcs, setuptools, and setuptools-scm, which are crucial for the new automated build and versioning process.
• Dynamic Package Versioning: The tabpfn-common-utils package in uv.lock no longer has a hardcoded version, allowing setuptools-scm to determine it automatically.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces automated versioning using hatch-vcs, which is a great improvement for managing deployments. The changes involve updating dependencies in uv.lock and adding a _version.py file to be populated by hatch-vcs. My main feedback is that the generated _version.py file should not be committed to the repository; it should be added to .gitignore to avoid version conflicts. Additionally, while reviewing the context, I noticed a potential inconsistency in pyproject.toml between the standard [project.optional-dependencies] and a custom [dependency-groups] section. This could cause issues with development environment setups and should be unified to have a single source of truth for dependencies.

[gemini-code-assist]

This file is generated by setuptools-scm and should not be tracked in version control, as indicated by the comment on line 2. Tracking this file will lead to unnecessary merge conflicts and noise in the commit history, as it contains commit-specific information and will be regenerated on each build.

It is highly recommended to add this file to your .gitignore to prevent it from being committed.