fix: pass resource aliases to file-level CommonResources#16945
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request adds support for resource name aliases by introducing a resource_name_aliases field to the Proto and CommonResource classes and ensuring its propagation throughout the schema generation process. A review comment identifies a potential debug leftover in an error message within wrappers.py where a raw dictionary is printed, suggesting its removal to ensure the output remains clean and user-friendly.
| f"To protect backward compatibility, explicitly alias one of these using " | ||
| f"the `--resource-name-alias` CLI parameter.\n" | ||
| f"Example: --resource-name-alias={msg.resource_type_full_path}:CustomName\n" | ||
| f"{seen_types}" | ||
| ) |
There was a problem hiding this comment.
The inclusion of {seen_types} in the error message appears to be a debug leftover. Printing a raw dictionary of objects in a user-facing error message is generally not recommended as it can be very verbose and difficult to read. If you intended to provide more context about the collision, consider formatting the output to only show the relevant conflicting types.
f"To protect backward compatibility, explicitly alias one of these using "
f"the --resource-name-alias CLI parameter.\\n"
f"Example: --resource-name-alias={msg.resource_type_full_path}:CustomName\\n"
)
Add a test case for resource name alias functionality in CommonResources. This is to support #16945.
3 participants
File-level resources (like imported dependencies) were previously starved of CLI aliases during dummy MessageType creation. This caused false-positive namespace collisions because the collision checker couldn't see the explicit aliases.
This wires
opts.resource_name_aliasesdown through api.py intoCommonResource.build()so the alias resolution works as originally intended.Fixes: #16952