Experimenting with DMCG flags to have more readable pydantic models

[hellt]

The initial goal was to find a solution for clashing names like SpecModel1, SpecModel22, etc.

The hope was in using this koxudaxi/datamodel-code-generator#2373 but it exploded the model by creating hundreds of files nested 50 dirs deep. Something is off.

see koxudaxi/datamodel-code-generator#1600

ADD2

Dots were removed from original schema nodes in the generation script to allow for non-module-based parsing by the DMCG.

ADD1

It seems the root cause of all of these issues with with DMCG doing smart stuff about schema nodes that contain dots. It promotes such models to module-based ones, and thus creates the nested directory structure.

If I replace the dots with _ in the schema names, then using the --parent-scoped-naming flag becomes an option again and I get much better results. Also in that case there is not more nested structure, and the output is a single file.

Now, all we might need at this point is for pydantic-eda generator script to download the models instead of referencing them via URL and in the downloaded models perform the subtitution of dots to underscores in the schema nodes.
In addition we can remove the com.nokia.eda prefix from the schema node to make it less hairy in the generated name.

Consider the following example of an model name that we provide as an input to the DMCG:

apps/components.eda.nokia.com/v1/components.json

Step 1:

From this input file name we can derive the application name, which is the components and the api version, which is v1.
Store these in the variables app_name, app_api_version

Step 2:

In the provided openapi file, transform the schema names so that an original name like this

com.nokia.eda.components.v1.ControlModule

becomes

ControlModule

We can strip all the info before the actual schema node name because we already know the app name and the api version.

By stripping the name to the bare schema name we achieve a clear Pydantic class name.

Step 3:

Now as the output for the generated class we will need to create a dir structure using the vars from step 1

app_name/app_api_name/app_name.py

That way we keep the app name and api version in the import path, and the generated classes are not fucked up anymore