mirror of
https://github.com/invoke-ai/InvokeAI
synced 2024-08-30 20:32:17 +00:00
ce9aeeece3
We have two problems with how argparse is being utilized: - We parse CLI args as the `api_app.py` file is read. This causes a problem pytest, which has an incompatible set of CLI args. Some tests import the FastAPI app, which triggers the config to parse CLI args, which receives the pytest args and fails. - We've repeatedly had problems when something that uses the config is imported before the CLI args are parsed. When this happens, the root dir may not be set correctly, so we attempt to operate on incorrect paths. To resolve these issues, we need to lift CLI arg parsing outside of the application code, but still let the application access the CLI args. We can create a external app entrypoint to do this. - `InvokeAIArgs` is a simple helper class that parses CLI args and stores the result. - `run_app()` is the new entrypoint. It first parses CLI args, then runs `invoke_api` to start the app. The `invokeai-web` project script and `invokeai-web.py` dev script now call `run_app()` instead of `invoke_api()`. The first time `get_config()` is called to get the singleton config object, it retrieves the args from `InvokeAIArgs`, sets the root dir if provided, then merges settings in from `invokeai.yaml`. CLI arg parsing is now safely insulated from application code, but still accessible. And we don't need to worry about import order having an impact on anything, because by the time the app is running, we have already parsed CLI args. Whew! |
||
---|---|---|
.. | ||
configure_invokeai.py | ||
generate_openapi_schema.py | ||
generate_profile_graphs.sh | ||
images2prompt.py | ||
invokeai-cli.py | ||
invokeai-model-install.py | ||
invokeai-web.py | ||
make_models_markdown_table.py | ||
probe-model.py | ||
pypi_helper.py | ||
scan_models_directory.py | ||
sd-metadata.py | ||
update_config_docstring.py |