fix:Additional plugins for evals #4236
Conversation
Summary of ChangesHello @jayy-77, I'm Gemini Code Assist1! 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 introduces a significant enhancement to the evaluation system by allowing users to provide custom plugins during the inference phase. This change empowers developers to extend the evaluation behavior with bespoke functionalities, such as advanced retry mechanisms, custom logging, or state management, without altering the core evaluation logic. The modifications ensure that these plugins are seamlessly integrated and utilized throughout the evaluation process. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe 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
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 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
|
|
Response from ADK Triaging Agent Hello @jayy-77, thank you for creating this PR! Could you please fill out the pull request description template? Specifically, please provide a description of the change, a testing plan, and fill out the checklist. This information will help reviewers to review your PR more efficiently. Thanks! |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
The pull request introduces a valuable feature by allowing additional plugins to be used during evaluation inference. The changes are well-structured, incorporating TYPE_CHECKING for conditional imports and ensuring that user-provided plugins are correctly merged with built-in ones. The addition of comprehensive unit tests for this new functionality is also commendable, demonstrating a thorough approach to testing. However, there is a type inconsistency in the InferenceConfig model that should be addressed for improved type safety and consistency across the codebase.
| could also overwhelm those tools.""", | ||
| ) | ||
|
|
||
| plugins: list[Any] = Field( |
There was a problem hiding this comment.
The plugins field in InferenceConfig is currently typed as list[Any]. While BasePlugin is conditionally imported for TYPE_CHECKING, this creates a type inconsistency with downstream functions (e.g., in evaluation_generator.py) that expect list[BasePlugin]. For better type safety and consistency, consider importing BasePlugin directly (not under TYPE_CHECKING) and typing this field as list[BasePlugin]. This would allow Pydantic to perform runtime validation and ensure type alignment throughout the codebase.
| plugins: list[Any] = Field( | |
| plugins: list[BasePlugin] = Field( |
| self, mocker, mock_runner, mock_session_service | ||
| ): | ||
| """Tests that custom plugins are merged with built-in plugins.""" | ||
| from google.adk.plugins.base_plugin import BasePlugin |
There was a problem hiding this comment.
It's generally good practice to place all import statements at the top of the file for better readability and consistency, unless there's a specific reason (like avoiding circular imports or very heavy imports only needed in rare paths). Moving this import to the top of the file would align with standard Python style guidelines.
| mocker, | ||
| ): | ||
| """Tests that custom plugins are passed through to EvaluationGenerator.""" | ||
| from google.adk.plugins.base_plugin import BasePlugin |
There was a problem hiding this comment.
Similar to the previous test file, it's generally good practice to place all import statements at the top of the file for better readability and consistency. Moving this import to the top of the file would align with standard Python style guidelines.
2 participants
Please ensure you have read the contribution guide before creating a pull request.
Link to Issue or Description of Change
1. Link to an existing issue (if applicable):
2. Or, if no issue exists, describe the change:
If applicable, please follow the issue templates to provide as much detail as
possible.
Problem:
A clear and concise description of what the problem is.
Solution:
A clear and concise description of what you want to happen and why you choose
this solution.
Testing Plan
Please describe the tests that you ran to verify your changes. This is required
for all PRs that are not small documentation or typo fixes.
Unit Tests:
Please include a summary of passed
pytestresults.Manual End-to-End (E2E) Tests:
Please provide instructions on how to manually test your changes, including any
necessary setup or configuration. Please provide logs or screenshots to help
reviewers better understand the fix.
Checklist
Additional context
Add any other context or screenshots about the feature request here.