For autogeneration of SDKs and API docs from an OpenAPI spec.
Candidates for evaluation:
More can be found here: https://openapi.tools/#sdk, although (at a glance) the two above seem to be the only ones that:
a) have an acceptable license
b) support the most popular languages, including Python
c) are actively maintained
https://github.com/fern-api/fern was initially considered but the free version of it is so minimal that it's useless.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | dschwen | T319953 Migrate panoviewer from Toolforge GridEngine to Toolforge Kubernetes | |||
| Open | None | T321919 Figure out and document how to call the Kubernetes API as your tool user from inside a pod | |||
| Open | dcaro | T356377 [toolforge] simplify calling the different toolforge apis from within the containers | |||
| Stalled | Feature | None | T309308 [jobs-cli,toolforge-cli] Add tfj as a shortcut for toolforge-jobs command | ||
| Open | None | T356262 [jobs-cli,builds-cli,toolforge-cli,webservice] Consolidate the Toolforge CLIs | |||
| In Progress | Slst2020 | T356261 [toolforge-cli,jobs-cli,builds-cli,envvars-cli] Explore OpenAPI SDK tooling for client consolidation |
OpenAPI Ggenerator and Swagger Codegen look very similar on the surface. A little digging reveals that OpenAPI Generator was forked from Swagger Codegen in 2018 by a group of the Swagger Codegen community and contributors who wanted to proceed in a slightly different direction. Their stated goals were to speed up development and acceptance of new features, improve the quality and maintainability of the code base, and make it easier for new contributors to get involved.
Swagger Codegen is sponsored by SmartBear Software, while OpenAPI Generator is community-driven. Both are actively maintained and distributed under the Apache-2.0 license. OpenAPI Generator has more stars/forks even though it's a newer project. OpenAPI Generator has (in my opinion) much better docs.
@dcaro What is our plan for creating the Toolforge CLI from the autogenerated SDK? Manually? Automatically with a post-generation script?
Will depend on the quality of the code generated, though I expect that there will always be some manual things we want to check, we could easily just create a new MR with the changes when any of the APIs is changed, for someone to review and merge right away if possible, or manually adapt if not.
So I guess eventually we might want something like:
Any api change -> generate toolforge python libs -> create MR on the toolforge cli to upgrade
Though we might start with something like:
Any api change -> create MR on the toolforge cli with the generated libs embedded
We can decide once we have the common API exposed though, no need to solve the problem yet.
Even assuming that the generated SDK does not need any manual changes, we would still have to create/modify the CLI for each change to the API. So if there is a change in the API that introduces a new endpoint, the autogenerated client will have a new method dealing with that, but implementing the CLI wrapper is still up to us. I'm not sure my original question was clear.
Even assuming that the generated SDK does not need any manual changes, we would still have to create/modify the CLI for each change to the API. So if there is a change in the API that introduces a new endpoint, the autogenerated client will have a new method dealing with that, but implementing the CLI wrapper is still up to us. I'm not sure my original question was clear.
Can you elaborate on your question? (in case I did not answer the question you were asking xd)