introduce engine for API #434
Conversation
| id: Optional[uuid.UUID] = None, | ||
| timestamp: Optional[datetime.datetime] = None, |
There was a problem hiding this comment.
It was kinda weird to not have these fields here given that we have them in the database as well as in the schema. Without them, converting back and forth became harder, because we'd need to keep track of this information manually.
| @@ -41,20 +45,69 @@ class Rag(Generic[C]): | |||
| ``` | |||
| """ | |||
|
|
|||
| def __init__(self) -> None: | |||
| self._components: dict[Type[C], C] = {} | |||
| def __init__( | |||
There was a problem hiding this comment.
Two new functionalities for the ragna.Rag object:
- When creating a new chat with
Rag().chat(), one now can also pass the display name of any loaded component instead of passing an instance or the class. - The object can now be created with a configuration object, which loads all configured source storages and assistants.
We had this before, but only for the API. While refactoring, it made the code a lot cleaner when moving it here.
| # TODO: the document endpoints do not go through the engine, because they'll change | ||
| # quite drastically when the UI no longer depends on the API |
There was a problem hiding this comment.
What the inline comment says. This will be addressed in the follow-up PR
|
|
||
|
|
||
| @pytest.fixture(scope="package", autouse=True) | ||
| def enhance_raise_for_status(package_mocker): |
There was a problem hiding this comment.
I was annoyed by the lack of information while debugging. response.raise_for_status() is a nice thing if you just want to check if there is an error. With this, we now automagically also see the content if something fails alongside the status code.
|
Test failures are unrelated and will be fixed by #435. |
First part of #392. This just introduces the engine and let's the API use it. After this is merged, I send a follow-up that refactors the UI to also use the engine, which in turn will complete #392.