Add model_path and model_version to telemetry tracking

[safaricd]

Change Description

• Track model_version and model_path

We track these using the same mechanics as extension_name - contextvars. What's the flow?

1. User instantiates e.g. TabPFNClassifier
2. During fit, we load the model - this is where for that model (presumably running in its own thread) loads the weights from HF.

[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 significantly enhances the telemetry system by introducing the tracking of model_path and model_version. This change provides more granular data on which specific models are being utilized, allowing for improved understanding of model deployment and usage patterns. The implementation leverages Python's contextvars to seamlessly integrate these new tracking capabilities into the existing telemetry framework.

Highlights

• Enhanced Telemetry Tracking: The system now tracks model_path and model_version for better insights into model usage.
• Context Variable Integration: model_path and model_version are managed using Python's contextvars, similar to how extension_name is handled.
• New Configuration Function: A set_model_config function has been introduced to set the model path and version within the current context.
• Event Data Enrichment: The ModelCallEvent class has been updated to include model_path and model_version fields, ensuring these details are captured with each model call.
• Version Update: The project version has been incremented from 0.2.6 to 0.2.7.

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

The pull request introduces telemetry tracking for model_path and model_version, which is a valuable addition. The changes involve updating version numbers, exporting new functions, and modifying the telemetry decorators and event structures to accommodate these new tracking parameters. The refactoring of _get_context_var to accept a variable name is a good improvement for reusability. However, there are a couple of areas in src/tabpfn_common_utils/telemetry/core/decorators.py that could be improved for robustness and error handling.

[brendan-priorlabs]

One problem with model path is that it can literally be a local machine path and thus contain PII. How about we take the end of the path and check it against a whitelist of our paths. See here: https://github.com/PriorLabs/tabpfn-server/blob/890b2e2f6796636772ec21915085041ec5b303df/packages/vertex_ai/src/vertex_ai/definitions.py#L132

[safaricd]

@brendan-priorlabs that's exactly what we're doing - we're just taking the name from the path, which should correspond to the name of the checkpoint - without taking the full path, which I agree, might contain PII. https://github.com/PriorLabs/tabpfn_common_utils/pull/45/files#diff-07f11f8e4b5926d243b55396530654190feb5b73399d0d1581a03a74bce59036R59

[oscarkey]

I like Brendan's suggestion of checking against the list of known checkpoints. People might also put PII in the file name.
Also, what do you think about very visibly doing this checking in tabpfn itself? This way users are less likely to worry what we're doing with their model path.

[safaricd]

@oscarkey I see where this is coming from - please check out the code in the tabpfn repo. We cannot check for this in the tabpfn_common_utils package because it doesn't have any "knowledge" of available models - nor it should. So passing this responsibility to the tabpfn package. https://github.com/PriorLabs/TabPFN/pull/611/files#diff-a995eff4877044df142c78beaee80244e0624c9493d1f2109ea14383bb66412eR498

[brendan-priorlabs]

LGTM! Just a couple cleanup comments