You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Wanted to start a discussion around the current naming conventions in the prost rules provided by rules_rust.
The prost rules set the crate name to the name of the proto_library that is being compiled.
This approach is very prone to clashes e.g. the following folder structure:
In this folder structure the common way to name the proto_library target would be models_proto (Which is the convention that gazelle uses) but that causes issues if there is a consumer that needs both service1/models and service2/models .
I think it makes sense to change the naming conventions or make them configurable since this is a very likely issue when you have a repo with a large protobuf codebase.
Options:
Change the naming convention to include the package path in the crate name
The example above would end with src_protobuf_service1_models_models_proto and src_protobuf_service2_models_models_proto
Make the convention configurable on the prost toolchain
The toolchain could provide a crate_naming_convention which accepts proto_name and package_name where proto_name would keep the current convention but package_name would include the package path in the crate name
The text was updated successfully, but these errors were encountered:
Wanted to start a discussion around the current naming conventions in the prost rules provided by rules_rust.
The prost rules set the crate name to the name of the proto_library that is being compiled.
This approach is very prone to clashes e.g. the following folder structure:
In this folder structure the common way to name the proto_library target would be models_proto (Which is the convention that gazelle uses) but that causes issues if there is a consumer that needs both service1/models and service2/models .
I think it makes sense to change the naming conventions or make them configurable since this is a very likely issue when you have a repo with a large protobuf codebase.
Options:
src_protobuf_service1_models_models_proto
andsrc_protobuf_service2_models_models_proto
crate_naming_convention
which acceptsproto_name
andpackage_name
whereproto_name
would keep the current convention butpackage_name
would include the package path in the crate nameThe text was updated successfully, but these errors were encountered: