Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[Feat]: Generate Pydantic models from proto definition for Python-idiomatic validation for A2A Version 1.0.x

Aperta
  • Qualcosa non va?
#884 33 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Ferma
Stack tecnologico
fastapi, python
Ambito
backend-api-design, tooling

Direzione di ricerca

L'issue riguarda la generazione di modelli Pydantic dal file a2a.proto. Esamina la pipeline di build esistente (probabilmente usando buf e protoc) nel repository. Cerca strumenti come protobuf-to-pydantic. Il lavoro consiste nel modificare il sistema di build per produrre un artefatto aggiuntivo. 'Done' significa che i modelli Pydantic generati vengono pubblicati nel pacchetto SDK insieme ai tipi proto.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

component: core
Is your feature request related to a problem? Please describe.

The migration to protobuf-generated types (PR #572) removes Pydantic models entirely from the SDK. While using a2a.proto as the single source of truth is the correct architectural decision, the removal of Pydantic models creates a significant developer experience gap for the Python ecosystem.

The problem:

  1. FastAPI, the most widely used Python web framework for building AI/agent services, uses Pydantic natively for request validation, serialization, OpenAPI schema generation, and error reporting. Proto objects don't integrate with any of this. Developers lose automatic validation, clear error messages, .model_dump(), .model_validate(), union discriminators, and Field() defaults.

  2. Protobuf objects in Python are not idiomatic. WhichOneof(), HasField(), CopyFrom(), MessageToDict()/ParseDict() are foreign patterns to Python developers building agents with LangChain, CrewAI, or custom FastAPI services. Proto3 has no required fields, so ParseDict({}, SendMessageRequest()) succeeds silently with an empty object, providing no validation at all.

  3. The v0.3.0 Pydantic types (generated from the OpenAPI spec via datamodel-codegen) were well-received and widely adopted. Multiple community frameworks depend on them for HTTP-layer validation. Removing them without replacement forces every downstream project to either vendor their own type definitions or wrap proto objects with manual validation boilerplate.

  4. This is visible in the issue tracker right now: #876 "SDK doesn't validate proto..." and #856 "Server does not validate..." are direct consequences of losing Pydantic's validation layer.

Describe the solution you'd like

Generate Pydantic models from the proto definition as an additional build artifact, alongside the existing proto-generated types. Both would be published in the SDK package.

Concretely:

  • a2a.types.proto (or a2a.grpc): Proto-generated types from a2a_pb2, as implemented in PR #572. Used by gRPC transport and anyone who prefers proto-native patterns.

  • a2a.types (or a2a.types.models): Pydantic models generated from the same a2a.proto source. Used for HTTP/JSON validation, FastAPI integration, and Python-idiomatic development.

Generation can be automated via protobuf-to-pydantic, custom protoc plugin, or a build script that derives Pydantic models from the OpenAPI/JSON schema (which is already generated from the proto via buf). The key point: a2a.proto remains the single source of truth. The Pydantic models are a generated artifact, not a manually maintained parallel type system.

This is not an either/or decision. The proto types serve gRPC consumers well. The Pydantic types serve the HTTP/JSON/FastAPI ecosystem. Both are generated from the same source, stay in sync automatically, and serve different transport layers of the same protocol.

The cost is one additional codegen step in the build pipeline. The benefit is that the Python SDK remains usable for the majority of Python agent developers who build on FastAPI/Pydantic.

Describe alternatives you've considered

No response

Additional context

No response

Code of Conduct
  • I agree to follow this project's Code of Conduct
Lingua principale
Python
Stelle
2.2k
Fork
499
Merge medio
3g 20h
PR unite (30g)
32

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di a2aproject/a2a-python

Tutte le issue di a2aproject/a2a-python

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.