refactor: Separate protobuf dependencies into sensible extras

[vinoo999]

Description

This introduces a proto extra into the package. The core library itself has no direct dependency on protobuf and only rest server and clients require a2a. google-api-core is only a dependency for grpc. Refactor accordingly to reduce dependency mangling introduced by proto for non grpc/rest servers. Assuming a CI regenerates the uv.lock file but can regenerate it otherwise.

This does not follow the runtime validation pattern in #217 as proto dependencies are localized in proto_utils.py.

• Follow the CONTRIBUTING Guide.
• Make your Pull Request title in the https://www.conventionalcommits.org/ specification.
  • Important Prefixes for release-please:
    • fix: which represents bug fixes, and correlates to a SemVer patch.
    • feat: represents a new feature, and correlates to a SemVer minor.
    • feat!:, or fix!:, refactor!:, etc., which represent a breaking change (indicated by the !) and will result in a SemVer major.
• Ensure the tests and linter pass (Run bash scripts/format.sh from the repository root to format)
• Appropriate docs were updated (if necessary)

[gemini-code-assist]

Summary of Changes

Hello @vinoo999, 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 refactors the project's dependency management by isolating protobuf-related packages into a new proto optional dependency. The primary goal is to reduce the core library's dependency footprint, ensuring that protobuf and google-api-core are only installed when explicitly required by components such as gRPC or REST servers. This change prevents unnecessary dependency conflicts and streamlines installations for users who do not utilize protobuf-dependent features, leading to a more modular and efficient dependency structure.

Highlights

• Dependency Refactoring: The core package dependencies have been streamlined by removing protobuf and google-api-core from the main dependencies list in pyproject.toml.
• New proto Optional Dependency: A new optional dependency, proto, has been introduced to encapsulate protobuf requirements, allowing for more granular installation.
• Updated Server Dependencies: The grpc and rest-server optional dependencies now explicitly require the new proto extra, ensuring protobuf-related packages are only installed when needed by these components. A new jsonrpc-server extra was also added, and http-server now depends on jsonrpc-server and rest-server.
• Dynamic Protobuf Imports: The src/a2a/utils/proto_utils.py file has been updated to handle google.protobuf imports dynamically, providing a clear ImportError message that guides users to install the proto extra if the dependency is missing.

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 effectively refactors the project's dependencies by separating protobuf into an optional [proto] extra. This is a great improvement for users who don't need Protobuf-related functionality, reducing the core dependency footprint. The changes in pyproject.toml correctly move the dependencies, and the try-except block in proto_utils.py provides a clear error message for missing optional dependencies. I have one suggestion in pyproject.toml to further improve the structure and maintainability of the optional dependencies for server implementations.

[holtskinner]

I'm not sure protobuf really needs to be a separate dependency group from grpc

[vinoo999]

can remove the extra altogether if you want to be explicit for the REST and gRPC servers. My goal was removing protobuf dependencies especially for JSON-RPC servers + clients.

If you prefer can do:

jsonrpc-server = ["fastapi>=0.115.2", "sse-starlette", "starlette"]
http-server = ["a2a-sdk[jsonrpc-server]", "protobuf>=5.29.5"]
grpc = ["grpcio>=1.60", "grpcio-tools>=1.60", "grpcio_reflection>=1.7.0", "google-api-core>=1.26.0", "protobuf>=5.29.5"]

[vinoo999]

http-server is a bit confusing naming of the extra now that JSON-RPC is split out but needed for backward compatibility

[holtskinner]

@pstephengoogle Can you review and make sure this follows with current plans for the protocol?

[sambhav]

@pstephengoogle / @holtskinner any updates on this?

[lkawka]

Why make changes to this file? It appears that entires were in an alphabetical order here.

[vinoo999]

unclear. i think this came directly from the github action when updating readme. i can revert

[vinoo999]

in fact I think this may have come from the Format script which must have a bug for capitalization

[vinoo999]

https://github.com/a2aproject/a2a-python/pull/550### to address

[vinoo999]

reran with ^ and applied. removed postres dup

[lkawka]

Can we leave it as it was? I'm not entirely familiar with how this file is used and I worry that dependents may be case-sensitive.

[holtskinner]

This was intentionally left case-sensitive, because the case-insensitive sort wasn't always consistent.

[lkawka]

Let's copy the terminology from the spec documentation: HTTP+JSON/REST Server

[lkawka]

HTTP+JSON/REST also requires these dependencies.

rest_handler.py depends on a2a_pb2:

a2a-python/src/a2a/server/request_handlers/rest_handler.py

Line 18 in 89e9b7c

from a2a.grpc import a2a_pb2

[vinoo999]

This is already encompassed here. a2a.grpc.a2a_pb2 has no grpcio dependencies. Just protobuf. This is encapsulated in the PR already.

Any concerns here?

[lkawka]

a2a_pb2 seems to depend on google-api-core:

a2a-python/src/a2a/grpc/a2a_pb2.py

Line 26 in 89e9b7c

from google.api import client_pb2 as google_dot_api_dot_client__pb2

I think we need to include it here as well.

[vinoo999]

You're right. I'll add some tests that do the individual extras plus tests accordingly. I'm going to move this PR to draft because it looks like 1.0 is going to require some changes that depend directly on the proto rather than the a2a spec json even in jsonrpc. In doing so this split may not be directly possible in the way I'd like.

[vinoo999]

Moving to draft. pending 1.0 will see if this is still possible. based on discussion the proto dependency might be required in all protocol bindings.