Command: generate_proto
Generates .proto files from registered gRPC services and (optionally) compiles Python stubs (*_pb2.py, *_pb2_grpc.py, and optionally *.pyi).
Basic usage:
python manage.py generate_proto --app <app_label>
What Command Does
- auto-discovers services (
{app}.grpc.servicesby default) - builds proto definitions from method schemas
- writes/updates app proto files
- optionally compiles proto to Python stubs
Options
--app <label>: process only selected app; can be repeated--all: process all installed apps--force: rewrite proto files even if content changed detection would skip--no-compile: only write.proto, skippb2generation--pyi: generate*.pyitype stubs during compile
Recommended patterns:
# one app
python manage.py generate_proto --app products
# all apps
python manage.py generate_proto --all
# regenerate and compile with type stubs
python manage.py generate_proto --app products --force --pyi
# proto only (for CI diff checks, for example)
python manage.py generate_proto --app products --no-compile
Typical Workflow
When service/schema code changed:
- run
generate_proto - commit updated
.protoand generated stubs - restart gRPC server
- refresh client descriptors in tooling (Postman/BloomRPC/etc.)
Multi-app Root Limitation
If apps are discovered under different include roots, command can raise:
Apps have different include roots; use --app for a single app root.
In that case, run command per app:
python manage.py generate_proto --app app_one
python manage.py generate_proto --app app_two
Common Errors
google/protobuf/empty.proto: File not found
Reason: protoc include path for bundled Google protos not resolved in environment.
What to check:
grpcio-toolsis installed in active venv- command is run from the same Python environment
- library version includes fixed protoc include resolution
AttributeError: type object 'list' has no attribute 'model_fields'
Reason: old generation path expected model class while method used top-level list[T] response schema.
Expected behavior in current implementation: list response schemas are supported and wrapped into repeated message payload.
Proto name conflicts
Example: duplicate message names for combined decorators/endpoints.
Fix:
- ensure latest library version with message name dedup logic
- avoid manually forcing identical explicit message names across incompatible schemas
Best Practices
- Use
--appin local development for faster iteration. - Use
--allin CI/release checks. - Keep generated files committed, so server and clients stay in sync.
- Use
--pyiif team relies on IDE/static typing for generated stubs. - Regenerate after changing decorators that alter request/response envelopes (
pagination,searching,ordering).