Relase: v1

[koxudaxi]

After fixing some major issues, the version will be 1.0.0

Candidate of the issues

• JSON Schema & Pydantic's default factory. #1026
• Default object defined as dict, not object #1024
• Infinite loop in generating models from JSONSchema #986
• Add support for Discriminator Object #957
• patternProperties is broken when used by reference #940
• Field Argument 'discriminator' has incorrect type (expected str, got dict) #934
• field-extra-keys in OpenAPI: Strip x- in the Field definition #916
• Parsing the Open Captable schema fails #909
• Generates duplicate model definitions from Kubernetes OpenAPI V3 input #894
• Importing generated code results in a circular dependency #836
• Prefix with the parent schema object name for inline child schemas with the same name #796
• Support multipleOfPrecision #760
• Needs support for new version of pydantic released (v1.9.0 (2021-12-31)) #681
• Predictable code generation #579

[ilovelinux]

IMHO there are a few other important thing that needs to be done before releasing v1:

Review of the generation flags.

When;

• A model is generated without any configuration

Then:

• The model should be as accurate as possible.
• The model should be as usable as possible

Instead:

• As now, there are a many flags that needs to be enabled to get this behavior.

E.g. #1812 suggest the removal of con* in favor of Annotation, which should be the default behavior, as suggested by Pydantic¹

They have been introduced as cli/configuration flags to not create breaking changes, but IMHO some of them should be considered default behaviors.

Improve decoupleing of Jsonschema and OpenAPI

As now, Jsonschema and OpenAPI generation models are strictly coupled, causing some generation issue.
E.g. Some OpenAPI types are considered valid in Jsonschema, but they should not.

Correctly support different Jsonschema/OpenAPI versions

As now, we have only one class for JsonSchema generation and another for OpenAPI generation. However different JsonSchema/OpenAPI versions behave differently (e.g. #2477 describes a behavior that should be applied happen only for OpenAPI v3.1 schemas)

Remove default base model

Many users are confused by the default behavior because it silently generates a Pydantic v1 model.
This issue is tracked by #2466

Use topological sort to generate models

As now, the algorithm that orders the generated models in the files sometimes behave incorrectly. We should use a topological sort instead. Since the project supports Python 3.9+, https://docs.python.org/3/library/graphlib.html could be used.

This should also be done for --collapse-root-models, which has been patched by #2465 but needs improvements

---

I may have missed something. Let me know what's your opinion about that! 🙂

Footnotes

1. https://docs.pydantic.dev/latest/api/types/#pydantic.types.confloat ↩

[koxudaxi]

@ilovelinux
Thanks for the suggestions. I mostly agree with these points.
One concern I have is about generation order. This has been a long-standing issue, but changing the logic has been difficult because it would significantly affect naming conventions and placement (especially when there are model name conflicts). For services running in production, large changes to model names can be painful to deal with.That said, the current state isn't ideal either, so this might be a good opportunity to address it. Perhaps a good starting point would be to test the new sorting logic on large OSS projects that use this CLI and assess the impact.
I agree with stricter support for JSON Schema and OpenAPI versions. This may require significant architectural changes, but it's worth pursuing.
In the short term, I'd like to prioritize addressing existing bug reports and implementing reasonable feature requests. I'll also continue gradual refactoring to make this a more modern and robust project. Additionally, there are various new features I'd like to add as options—I'm not sure how valuable they'll all be, but I'd like to explore them before committing all resources to v1.
Feel free to share your thoughts, everyone. This project aims to be a useful tool for the community.