Created by: VamshikShetty
PR checklist
-
Read the contribution guidelines. -
Ran the shell script under ./bin/
to update Petstore sample so that CIs can verify the change. (For instance, only need to run./bin/{LANG}-petstore.sh
,./bin/openapi3/{LANG}-petstore.sh
,./bin/security/{LANG}-petstore.sh
and./bin/openapi3/security/{LANG}-petstore.sh
if updating the {LANG} (e.g. php, ruby, python, etc) code generator or {LANG} client's mustache templates). Windows batch files can be found in.\bin\windows\
. -
Filed the PR against the correct branch: master
,. Default:3.4.x
,4.0.x
master
. -
Copied the technical committee to review the pull request if your PR is targeting a particular programming language.
@taxpon @frol @mbohlool @cbornet @kenjones-cisco @tomplus @Jyhess
Description of the PR
I was faced with the issue of modularising my api methods into different section, this need arised due to the fact that my main_package had its own independent openapi specification file. While on the other hand I had N number of sub packages which had their own independent openapi spec files but lets say that a user only wants selective k packages to be installed independently hence using this merge he can generate selective k binding by running Codegen k times with new specification files of each subpackage, while making sure all sub_packages refer to common api client, configuration and rest python files i.e structure should be similar to :
This particular PR talks foundational bug which was later resolved in it.
So lets say if user wants to install sub_package_1, sub_package_7 and sub_package_13 (assuming main_package is default) then First he create main_package normally like any openAPI auto generated client bindings by passing openapi specs and config file. config file:
{
"packageName":"main_package",
"projectName":"python-main-package",
}
Then by generating openapi bindings of sub_package_1, sub_package_7 and sub_package_13 but considering client's packageName as its root package to refer to main_package api_client. sub_package_1 config file:
{
"packageName": "main_package",
"invokerPackage" : "sub_package_1",
"generateSourceCodeOnly":true
}
This led me to use a new parameter named invokerPackage in config file.
Changes that I have done:
-
I have added three new mustache files, first two append_submodule_api_details.mustache and append_submodule_model_details.mustache files are used to create content that will be append into main_packge/api/init.py and main_packge/model/init.py respectively. And third one __init__package_submodule.mustache which acts as a sub package init.py file without referring to api_client of main_package. commit 1 commit 2
-
Added reference of main_package/api and main_package/models in main_package/init.py so main package init can point to sub packages classes which are referred in main_package/api/init.py. commit
-
Merge function added to add details of new api classes to main_package/api/init.py which is generated at the time of sub_package generation also sub_package models details to main_package/models/init.py commit 1 commit 2 commit 3
-
Usage of Invoker package to create path to generate sub package's api, models and package init. commit