Closed niamiot closed 1 week ago
I haven't used this version of proto, so I haven't noticed this headache.In order to be compatible with as many proto versions as possible, I may add a new configuration item which by enabling it can be used to generate code compatible with this version of proto. @niamiot
It would be very nice if you can consider this. it will probably help a lot of other dev to cope with this « headache » as you said :) Thank you for this, and for your whole project ( it’s really awesome)
Hi,
I open this bug in relation with this closed issue. This issue has been solved by supposing the pydantic optional fields are the result of the proto's "optional" keyword. but AFAIU, it is not. By default all fields in proto3 should be considered as optional, and consequently all the generated pydantic objects should be typing.Optional[]. ( the "optional" keyword in proto has been initially deprecated in proto3 and re-introduced starting v3.15).
Base the fact that a pydantic object field is optional only from the "optional" proto3 keyword is an issue when you work with versions
3.0 <= protoc < 3.15
. In this case, despite your proto object is optional, the generated pydantic field is not.I'm actually stuck because I have to work with 2 versions of protoc (v3.11 & 3.20) sharing the same proto files, and I cannot generate correct pydantic object for v3.11.
Come what may, if you have a solution to force the field to be optional , You'll be very welcome.
Thank you very much
To Reproduce
Actual behavior
Expected behavior
Additional Information As mentionned before, it work with protoc > 3.15 using the optional keyword