Each field is of type optional, although it is not specified as optional in .proto

[taimast]

Summary

Each field is of type optional, although it is not specified as optional in .proto

Reproduction Steps

How can this be controlled to match the proto file?

message ComponentInfo {
  string id = 1;
}

message LinkPreviewFeature {
  components.component.info.v1.ComponentInfo component_info = 1;
}

@dataclass(eq=False, repr=False)
class LinkPreviewFeature(betterproto2.Message):
    component_info: "__component__info__v1__.ComponentInfo | None" = betterproto2.field(
        1, betterproto2.TYPE_MESSAGE, optional=True
    )

Expected Results

matching the optional specification in the proto file

Actual Results

Each field is of type optional, although it is not specified as optional in .proto

System Information

╰─ uv tree
Resolved 18 packages in 0.86ms
autoanswer-proto v0.1.0
├── betterproto2 v0.5.1
│   ├── python-dateutil v2.9.0.post0
│   │   └── six v1.17.0
│   ├── typing-extensions v4.13.2
│   └── grpclib v0.4.7 (extra: grpclib)
│       ├── h2 v4.2.0
│       │   ├── hpack v4.1.0
│       │   └── hyperframe v6.1.0
│       └── multidict v6.4.3
├── betterproto2-compiler v0.5.1
│   ├── betterproto2[grpclib] v0.5.1 (*)
│   ├── jinja2 v3.1.6
│   │   └── markupsafe v3.0.2
│   ├── ruff v0.9.10
│   └── typing-extensions v4.13.2
└── grpcio-tools v1.71.0
    ├── grpcio v1.71.0
    ├── protobuf v5.29.4
    └── setuptools v79.0.0
(*) Package tree already displayed

Checklist

• I have searched the issues for duplicates.
• I have shown the entire traceback, if possible.
• I have verified this issue occurs on the latest prelease of betterproto which can be installed using pip install -U --pre betterproto, if possible.

[AdrienVannson]

Thank you for your feedback. This is not a bug: in proto3, explicit presence is used for message fields, whether they are defined as optional or not.

See https://protobuf.dev/programming-guides/field_presence/ and this paragraph: https://protobuf.dev/programming-guides/proto3/#field-labels

[taimast]

Thank you for your feedback. This is not a bug: in proto3, explicit presence is used for message fields, whether they are defined as optional or not.

See protobuf.dev/programming-guides/field_presence and this paragraph: protobuf.dev/programming-guides/proto3#field-labels

Yes, I understand what you're talking about. In the original version of betterproto, the Optional type is used exactly when it is specified in the proto files. My entire large codebase used betterproto of the first version, so when switching to betterproto2, it led to endless errors. Therefore, my question was precisely about the ability to control this behavior so that the transition from betterproto1 would be less painful.

[yamatiro]

@AdrienVannson Perhaps it would be a better solution to add an argument for the compiler to choose whether to do so or not, because I have now switched from the first version of betterproto, and there the optional in the generated files is indicated only if the optional is specified in the proto files, and this breaks the transition

[AdrienVannson]

Thank you for your comments, I answered here: #73