Skip to content

Conversation

@rofrankel
Copy link
Contributor

Inspired by a recent convo on our Slack channel, this PR breaks ground on having type libraries for the AEP types.

To keep things simple, this PR just adds support for one language (Python) and one simple type (Decimal). If the overall approach looks good, we can add support for more types and languages.

(Note: this PR was generated by http://jules.google)

This commit updates the project metadata in the `pyproject.toml` file to reflect the correct author, homepage, and bug tracker URLs as requested.
This commit fixes the formatting of the `python/README.md` file to align with the project's prettier configuration.
Copy link
Member

@rambleraptor rambleraptor left a comment

Choose a reason for hiding this comment

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

Broadly speaking, this is exactly what I had in mind. Convert AEP types <-> language-specific types.

@@ -0,0 +1,24 @@
# Generated by the gRPC Python protocol compiler plugin. DO NOT EDIT!
Copy link
Member

Choose a reason for hiding this comment

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

high-level what is the strategy for these generated files? it seems like we'll check it in, but is there a how-to on how to generate these?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added a regenerate.sh script that basically just runs buf generate.

@toumorokoshi
Copy link
Member

Overall looks good to me! I'm a little back and forth about the to/from interface (feels like we should be using some more enum-focused serde, but with python's typing this might be best we can get.

+1 to using the native data types and translated to / from that, rather than forcing adoption of some separate typing system (e.g. protobuf directly)

@toumorokoshi
Copy link
Member

I think we should also consider whether we can structure the codegen a bit so that we can code-generate the serde functions in a standard way (e.g. using some yaml metadata file). I know that gapic libraries took the tact of being hand-coded by I don't think that's going to be super maintainable long-term.

@rofrankel
Copy link
Contributor Author

I think we should also consider whether we can structure the codegen a bit so that we can code-generate the serde functions in a standard way (e.g. using some yaml metadata file).

Can you elaborate a bit on how this would work? It seems pretty complicated, would have to handle a mix of built-in types (decimal) and custom ones (Money), etc.

I know that gapic libraries took the tact of being hand-coded by I don't think that's going to be super maintainable long-term.

With LLMs I think it's actually not such a big deal, but maybe you have different kinds of issues in mind than what I'm thinking of.

Copy link
Member

Choose a reason for hiding this comment

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

maybe this can be a module (decimal.py)? simple enough that it doesn't need to be a package.

google-labs-jules bot and others added 3 commits October 31, 2025 19:23
This commit introduces a script to regenerate the Python files from their protobuf definitions.

The changes include:
- A new `python/regenerate.sh` script that uses `buf generate` to handle code generation.
- An updated `buf.gen.yaml` to correctly configure the Python and gRPC plugins using the v2 syntax.
- Updated import paths in the Python code to reflect the new generated structure.
- Updated `python/README.md` to document the new script.
feat: Add script to regenerate protobuf files
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants