InvokeAI/scripts/generate_openapi_schema.py

import json
import os
import sys


def main():
    # Change working directory to the repo root
    os.chdir(os.path.abspath(os.path.join(os.path.dirname(__file__), "..")))

    from invokeai.app.api_app import app
    from invokeai.app.util.custom_openapi import get_openapi_func

    schema = get_openapi_func(app)()
    json.dump(schema, sys.stdout, indent=2)


if __name__ == "__main__":
    main()
feat(scripts): add script to generate openapi schema 2024-03-06 02:36:15 +00:00			`import json`
			`import os`
			`import sys`


			`def main():`
			`# Change working directory to the repo root`
			`os.chdir(os.path.abspath(os.path.join(os.path.dirname(__file__), "..")))`

fix(app): openapi schema generation Some tech debt related to dynamic pydantic schemas for invocations became problematic. Including the invocations and results in the event schemas was breaking pydantic's handling of ref schemas. I don't really understand why - I think it's a pydantic bug in a remote edge case that we are hitting. After many failed attempts I landed on this implementation, which is actually much tidier than what was in there before. - Create pydantic-enabled types for `AnyInvocation` and `AnyInvocationOutput` and use these in place of the janky dynamic unions. Actually, they are kinda the same, but better encapsulated. Use these in `Graph`, `GraphExecutionState`, `InvocationEventBase` and `InvocationCompleteEvent`. - Revise the custom openapi function to work with the new models. - Split out the custom openapi function to a separate file. Add a `post_transform` callback so consumers can customize the output schema. - Update makefile scripts. 2024-05-29 07:29:51 +00:00			`from invokeai.app.api_app import app`
			`from invokeai.app.util.custom_openapi import get_openapi_func`
feat(scripts): add script to generate openapi schema 2024-03-06 02:36:15 +00:00
fix(app): openapi schema generation Some tech debt related to dynamic pydantic schemas for invocations became problematic. Including the invocations and results in the event schemas was breaking pydantic's handling of ref schemas. I don't really understand why - I think it's a pydantic bug in a remote edge case that we are hitting. After many failed attempts I landed on this implementation, which is actually much tidier than what was in there before. - Create pydantic-enabled types for `AnyInvocation` and `AnyInvocationOutput` and use these in place of the janky dynamic unions. Actually, they are kinda the same, but better encapsulated. Use these in `Graph`, `GraphExecutionState`, `InvocationEventBase` and `InvocationCompleteEvent`. - Revise the custom openapi function to work with the new models. - Split out the custom openapi function to a separate file. Add a `post_transform` callback so consumers can customize the output schema. - Update makefile scripts. 2024-05-29 07:29:51 +00:00			`schema = get_openapi_func(app)()`
feat(scripts): add script to generate openapi schema 2024-03-06 02:36:15 +00:00			`json.dump(schema, sys.stdout, indent=2)`


			`if __name__ == "__main__":`
			`main()`