danielgtaylor / danielgtaylor/python-betterproto
Import bug - Message from Capitalized package is mistaken for Nested Type
- Dominant language
- Python
- Stars
- 1.8k
- Forks
- 234
- PR merge metrics
- No merged PRs in 30d
Description
The compiler does not distinguish the following two cases:
```protobuf
package somepackage.Core;
message Message {}
```
```protobuf
package somepackage;
message Core {
message Message {}
}
```
as they are both:
```
somepackage.Core.Message
```
Protoc (as far as I've been able to figure out) reports the full type name, but not which part of that is the package, and which is the real type (`somepackage.Core: Message` vs `somepackage: Core.Message`).
In 99% of cases, this will not be a problem, because if users will follow the Protobuf Style Guide, packages will be `lowercase`, and types `CapitalCamelCase`, and the distinction can be made based on that.
https://developers.google.com/protocol-buffers/docs/style#packages
> Package name should be in lowercase, and should correspond to the directory hierarchy. e.g., if a file is in my/package/, then the package name should be my.package.
https://developers.google.com/protocol-buffers/docs/style?hl=cs-CZ#message-and-field-names
> Use CamelCase (with an initial capital) for message names – for example, SongServerRequest. Use underscore_separated_names for field names (including oneof field and extension names) – for example, song_name.
Despite these style guides, there may be some users who are using Capitalized packages and for some reason cannot change the packages to lowercase.
Then, these packages will not be imported correctly from depending packages / messages.
Contributor guide
Research direction
Start by reproducing the two protobuf package/message examples and compare how protoc reports their full type names during dependent imports. Trace the compiler's package and nested-type resolution entry point, then add coverage showing both cases are imported distinctly without breaking lowercase-package behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- compilers
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100