Doing some review, sorry for the delay. I'd like to ask for a high-level description in this MR for how this integration works, with especial focus on how structs are handled (in particular how the JSON <-> struct boundary is handled).

As a subsequent follow up, one idea for a way to handle unions would resemble this:

class MyEnumVariant1:
    type: Literal["Variant1"]
    content: MyEnumVariant1Content

...

MyEnum = Union[MyEnumVariant1, ...]

I'm still a novice around pydantic, so there could certainly be a better way that I'm not aware of. For all I know this pattern is fully built-in to pydantic somewhere and I just don't know where.

As a subsequent follow up, one idea for a way to handle unions would resemble this:

class MyEnumVariant1:
    type: Literal["Variant1"]
    content: MyEnumVariant1Content

...

MyEnum = Union[MyEnumVariant1, ...]

I'm still a novice around pydantic, so there could certainly be a better way that I'm not aware of. For all I know this pattern is fully built-in to pydantic somewhere and I just don't know where.

After some experimentation and discussion with @MOmarMiraj, I think this is the best approach for externally tagged enums. I've refactored the PR to do so.

Hey all! I'm ready to approve once the remaining feedback is address (or marked Will Not Fix)

For future improvement, let me know if I've missed anything.

1. conint from pydantic can be used for further validation. For example, if the Rust type is u8, then we can leverage conint to bound the number from 0 to 255.

2. struct and enum with generic parameters are not supported. For example, the test case can_generate_generic_enum is not enabled for Python as it is not supported.

3. Rust enum must be adjacently tagged, like #[serde(tag = "t", content = "c")], other enum representations, such as internally tagged and untagged are not supported. Read more about enum representation with serde here: https://serde.rs/enum-representations.html. Correct me if I am wrong but I believe this is a limitation in Typeshare itself

4. Type overriding with the #[typeshare] macro is not supported. See the test can_override_types for details.

Thanks @CheatCod! I've captured these in #217 to make sure we don't lose track of them once merging this PR. I've resolved all the outstanding conversations after making sure they have either been logged as a future improvement or actually resolved.

@Lucretiel I think this should be ready to go! Let me know if you have any other questions or concerns 👍