[REQ] Creating a new generator using Kotlin as language

[Fjolnir-Dvorak]

I want to create a new python generator that is inspired by the Haskell generator. The current python-generator for a server is not usable without editing the generated code. I want to create a new one where no single code change is necessary to get a working server to ease the process of updating the server without the need to merge the code changes manually.

I really appreciate the language Kotlin along with its type safety and null safety which makes it easier to produce a more readable and secure code base.

[jimschubert]

I'm a little confused by the request. We have 2 Kotlin server generators and a Kotlin client generator which supports a handful of libraries/options.

Your description discusses python and Haskell generators and then comments about liking Kotlin. Are you looking for instructions to contribute a new generator for a framework that you're creating? If so, please use the kotlin-spring or kotlin generators as examples.

[Fjolnir-Dvorak]

I do not want to write a kotlin generator for now. I want to write a python generator in kotlin

[wing328]

The current python-generator for a server is not usable without editing the generated code

Can you please elaborate on that before creating a new generator? Is the issue with the Python Flask generator of Python AIOHTTP server?

cc @Jyhess (creator of Python AIOHTTP server generator?

cc @taxpon (2017/07) @frol (2017/07) @mbohlool (2017/07) @cbornet (2017/09) @kenjones-cisco (2017/11) @tomplus (2018/10)

[Fjolnir-Dvorak]

The issue is with both flask and client. I do not know anything about the first.
The "fix" I am creating for myself is not quite a small change in the structure of the project.

About the problem in python-flask:
I want to use the pythoin-flask server in a dedicated package as a library I will never touch and never edit. The current generator is creating a controller which is hard-wired with the backend. As far as I understand the code it is intended that the user should rewrite the generated controller files. That is a pain in the neck because we are changing/extending our api quite rapidly at the moment and we cannot simply regenerate all generated files because the project is intended as top-level code and wants it to be changed.
About the python client:
The python client is also intended as toplevel package. In my service I have to generate, and also regenerate multiple clients. When I keep the generated code separate from each other I have for example two packages "client.server1" and "client.server2". When I am adding those root-directories to my python path (sys.path) only the first one is registered and the second one is ignored.
To make that change possible I have to change both generators to be embeddable.

One further thing which I personally do not like:
The Haskell client generator generates code which is not bound to a client or a server, but is both at the same time. My goal here is to create a new python generator project layout where I can use the created code as a client or a server without redundant stuff or transferring the same object from package a to package b if I want to create a server serving Schema A and speaking to another Server with the same schema. (who knows? some kind of proxy or validator could do that)

[jimschubert]

I do not want to write a kotlin generator for now. I want to write a python generator in kotlin

I see, thanks for the clarification!

I had discussed using Kotlin with the core team, and we decided to stay with Java as we perform some large refactors over the next couple of releases… then we'd evaluate again later. I also like Kotlin (it's what I've written intellij-openapi-generator in).

openapi-generator supports three generator/template types:

• Built-in generators and their templates
• User-defined templates
• User-defined generators

As already suggested above, the generator/template maintainers may be able to offer a recommendation for an approach. We also welcome community contributions to improve all generators.

Sometimes we do have edge cases or special use cases that don't seem to fit into the built-in generators. If that is the case, you can make your own private generator. Even as a core team member, I've made a few custom generators at work. To create a user-defined generator, you can use the meta command on the CLI to get started. The end result is an artifact which, when it exist on your classpath, will be available to openapi-generator. You should be able to use any JVM language for this artifact, as long as the types are compatible with Java.

You can see a full example of extending a built-in generator (and how to consume this) in this repo: https://github.com/jimschubert/custom-generator-example. I have an open pull request to improve our documentation strategy, and you can check out the customization doc from my branch here: https://github.com/OpenAPITools/openapi-generator/blob/0750ef9337681ebb0268919398a67bcc7d9ea98d/docs/customization.md

[Fjolnir-Dvorak]

Thank you for your response. I suppose that I the core team plans a clean up in the future that every generator will be removed from the core module and will be put into a custom module which could be included into the core via maven/gradle.
If that would be the case I suppose writing a user-defined generator is the way to go and would be the best solution to be embeddable into the core module if the generator should be included.
If that is the case I would create a new (or search) a new issue for a new git project as a base for a code-generator which fulfils the standards and requirements to be embeddable into the core module like Contribution Guide, License, Code Style formatter etc.

[jimschubert]

@Fjolnir-Dvorak to clarify, we don't have plans to extract out generators to separate projects/modules or repos. Our plans are centered around refactoring the core code such that we can better hide internals and expose a cleaner public API to be consumed by authors of both custom generators and custom templates.

For details, you can check out our Roadmap.

[Fjolnir-Dvorak]

Ok, thank you. I guess that the main question if kotlin can be used as an alternative to java to write the code was rejected leaving the new question open if a new generator should be implemented as a core-generator or as a module where I do not know how users should find whose in the wonky wide web which was not the primary question of this ticket so I guess the question is answered and I can close the ticket.