8000 [for testing purposes] : Run latest mypy on fragments by parthea · Pull Request #2578 · googleapis/gapic-generator-python · GitHub
[go: up one dir, main page]

Skip to content

[for testing purposes] : Run latest mypy on fragments#2578

Draft
parthea wants to merge 3 commits intomainfrom
run-mypy-on-fragments-latest
Draft

[for testing purposes] : Run latest mypy on fragments#2578
parthea wants to merge 3 commits intomainfrom
run-mypy-on-fragments-latest

Conversation

@parthea
Copy link
Contributor
@parthea parthea commented Mar 11, 2026

No description provided.

@product-auto-label product-auto-label bot added the size: xl Pull request size is extra large. label Mar 11, 2026
@parthea parthea force-pushed the run-mypy-on-fragments-latest branch 2 times, most recently from 0d99262 to e49ad70 Compare March 11, 2026 11:54
@parthea parthea changed the title [for testing purposes] : Run mypy on fragments latest [for testing purposes] : Run latest mypy on fragments Mar 11, 2026
@gemini-code-assist
Copy link
Contributor

Summary of Changes

Hello, 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 primarily focuses on enhancing the testing infrastructure by integrating mypy static type checking for generated code fragments. It introduces new .proto files as test fragments, specifically for Google Cloud IAM and resource management APIs, to validate the type correctness of the generated client code. Additionally, it refines the request initialization logic in test templates to accommodate various request object types.

Highlights

  • Mypy Integration for Fragments: The testing framework (noxfile.py) was updated to allow running mypy type checks on generated code fragments, enabling static analysis for these components.
  • Proto Fragment Additions: Several new .proto files were added under tests/fragments/, introducing Google API definitions for resource, iam_policy, options, policy, and expr, along with a test IAM service. These are likely to serve as new test cases for the mypy checks.
  • Request Type Handling: The _test_mixins.py.j2 template was adjusted to correctly handle different request_type inputs (dictionaries vs. native protobufs) when initializing requests, ensuring proper argument passing.
Changelog
  • gapic/ads-templates/tests/unit/gapic/%name_%version/%sub/_test_mixins.py.j2
    • Modified request initialization to conditionally use dict() or ** for request_type based on whether it's a dictionary or a native protobuf type.
  • noxfile.py
    • Added a mypy_only parameter to the FragTester class constructor.
    • Implemented conditional logic within FragTester.__call__ to run mypy checks if mypy_only is true, otherwise run py.test.
    • Refactored the fragment Nox session to use a run_tests helper function, allowing it to first run unit tests and then install mypy and related type stubs, followed by running mypy checks on the fragments.
  • tests/fragments/google/api/resource.proto
    • Added a new proto file defining ResourceDescriptor and ResourceReference messages, including extensions for FieldOptions, FileOptions, and MessageOptions.
  • tests/fragments/google/iam/v1/iam_policy.proto
    • Added a new proto file defining the IAMPolicy service with SetIamPolicy, GetIamPolicy, and TestIamPermissions RPCs, along with their request/response messages.
  • tests/fragments/google/iam/v1/options.proto
    • Added a new proto file defining the GetPolicyOptions message.
  • tests/fragments/google/iam/v1/policy.proto
    • Added a new proto file defining Policy, Binding, AuditConfig, AuditLogConfig, PolicyDelta, BindingDelta, and AuditConfigDelta messages.
  • tests/fragments/google/type/expr.proto
    • Added a new proto file defining the Expr message for Common Expression Language.
  • tests/fragments/test_iam.proto
    • Added a new proto file defining a MyServiceIamMethods service with a SetIamPolicy RPC, importing the newly added IAM protos.
Activity
  • No human activity has been recorded for this pull request yet.
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.

Copy link
Contributor
@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request adds mypy checking for generated code fragments by modifying the noxfile.py to run pytest and then mypy. The implementation is functionally correct, but it introduces an inefficiency by generating code from fragments twice. My review includes a suggestion to refactor the test execution flow to avoid this redundant work and improve performance.

noxfile.py Outdated
Comment on lines +196 to +210

def run_tests(mypy_only=False):
"""Helper to handle the parallel vs sequential toggle."""
tester = FragTester(session, use_ads_templates, mypy_only=mypy_only)

if is_parallel:
with ThreadPoolExecutor() as p:
results = p.map(tester, frag_files)
session.log("".join(results))
else:
for frag in frag_files:
session.log(tester(frag))

output = "".join(all_outs)
session.log(output)
else:
tester = FragTester(session, use_ads_templates)
for frag in frag_files:
session.log(tester(frag))
run_tests(mypy_only=False)
session.install("mypy", "types-protobuf", "types-requests")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

The current implementation generates code from fragments twice: once for running pytest and a second time for mypy. This happens because run_tests is called twice, and code generation is part of the FragTester callable it uses.

This is inefficient. Consider refactoring to generate code only once per fragment. You could generate all fragment code first, then run pytest on all of them, and finally run mypy on all of them. This would avoid the redundant generation step and speed up the tests.

@parthea parthea force-pushed the run-mypy-on-fragments-latest branch from fae9bd7 to d8131f2 Compare March 11, 2026 14:21
@parthea parthea force-pushed the run-mypy-on-fragments-latest branch from d8131f2 to 6410633 Compare March 11, 2026 15:55
@product-auto-label product-auto-label bot added size: l Pull request size is large. and removed size: xl Pull request size is extra large. labels Mar 11, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

size: l Pull request size is large.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant

0