feat: refactor services folder/module structure
Refactor services folder/module structure.
**Motivation**
While working on our services I've repeatedly encountered circular imports and a general lack of clarity regarding where to put things. The structure introduced goes a long way towards resolving those issues, setting us up for a clean structure going forward.
**Services**
Services are now in their own folder with a few files:
- `services/{service_name}/__init__.py`: init as needed, mostly empty now
- `services/{service_name}/{service_name}_base.py`: the base class for the service
- `services/{service_name}/{service_name}_{impl_type}.py`: the default concrete implementation of the service - typically one of `sqlite`, `default`, or `memory`
- `services/{service_name}/{service_name}_common.py`: any common items - models, exceptions, utilities, etc
Though it's a bit verbose to have the service name both as the folder name and the prefix for files, I found it is _extremely_ confusing to have all of the base classes just be named `base.py`. So, at the cost of some verbosity when importing things, I've included the service name in the filename.
There are some minor logic changes. For example, in `InvocationProcessor`, instead of assigning the model manager service to a variable to be used later in the file, the service is used directly via the `Invoker`.
**Shared**
Things that are used across disparate services are in `services/shared/`:
- `default_graphs.py`: previously in `services/`
- `graphs.py`: previously in `services/`
- `paginatation`: generic pagination models used in a few services
- `sqlite`: the `SqliteDatabase` class, other sqlite-specific things
2023-09-24 08:11:07 +00:00
|
|
|
# Copyright (c) 2023 Lincoln Stein (https://github.com/lstein) and the InvokeAI Development Team
|
|
|
|
|
|
|
|
"""
|
|
|
|
Base class for the InvokeAI configuration system.
|
|
|
|
It defines a type of pydantic BaseSettings object that
|
|
|
|
is able to read and write from an omegaconf-based config file,
|
|
|
|
with overriding of settings from environment variables and/or
|
|
|
|
the command line.
|
|
|
|
"""
|
|
|
|
|
|
|
|
from __future__ import annotations
|
|
|
|
|
|
|
|
import argparse
|
|
|
|
import pydoc
|
|
|
|
from typing import Union
|
|
|
|
|
|
|
|
|
|
|
|
class PagingArgumentParser(argparse.ArgumentParser):
|
|
|
|
"""
|
|
|
|
A custom ArgumentParser that uses pydoc to page its output.
|
|
|
|
It also supports reading defaults from an init file.
|
|
|
|
"""
|
|
|
|
|
2024-02-13 05:26:49 +00:00
|
|
|
def print_help(self, file=None) -> None:
|
feat: refactor services folder/module structure
Refactor services folder/module structure.
**Motivation**
While working on our services I've repeatedly encountered circular imports and a general lack of clarity regarding where to put things. The structure introduced goes a long way towards resolving those issues, setting us up for a clean structure going forward.
**Services**
Services are now in their own folder with a few files:
- `services/{service_name}/__init__.py`: init as needed, mostly empty now
- `services/{service_name}/{service_name}_base.py`: the base class for the service
- `services/{service_name}/{service_name}_{impl_type}.py`: the default concrete implementation of the service - typically one of `sqlite`, `default`, or `memory`
- `services/{service_name}/{service_name}_common.py`: any common items - models, exceptions, utilities, etc
Though it's a bit verbose to have the service name both as the folder name and the prefix for files, I found it is _extremely_ confusing to have all of the base classes just be named `base.py`. So, at the cost of some verbosity when importing things, I've included the service name in the filename.
There are some minor logic changes. For example, in `InvocationProcessor`, instead of assigning the model manager service to a variable to be used later in the file, the service is used directly via the `Invoker`.
**Shared**
Things that are used across disparate services are in `services/shared/`:
- `default_graphs.py`: previously in `services/`
- `graphs.py`: previously in `services/`
- `paginatation`: generic pagination models used in a few services
- `sqlite`: the `SqliteDatabase` class, other sqlite-specific things
2023-09-24 08:11:07 +00:00
|
|
|
text = self.format_help()
|
|
|
|
pydoc.pager(text)
|
|
|
|
|
|
|
|
|
|
|
|
def int_or_float_or_str(value: str) -> Union[int, float, str]:
|
|
|
|
"""
|
|
|
|
Workaround for argparse type checking.
|
|
|
|
"""
|
|
|
|
try:
|
|
|
|
return int(value)
|
|
|
|
except Exception as e: # noqa F841
|
|
|
|
pass
|
|
|
|
try:
|
|
|
|
return float(value)
|
|
|
|
except Exception as e: # noqa F841
|
|
|
|
pass
|
|
|
|
return str(value)
|