Currently one needs to have a config file, e.g. ragna.toml, to serve Ragna (ragna ui and ragna api). Meaning, users will have to either run the interactive wizard to create one (ragna init) or copy and paste an example from our documentation. That is sub-optimal user experience, because extra steps are required (see #180).
However, this is only an issue for serving locally. When using docker, we have solved this by providing a default configuration. We do this, because it involves even more steps to be able to use a user created configuration inside a docker container.
We could bring the same UX from the docker image to local deployment as well. Meaning
We do provide a default config if -c / --config is not supplied.
We use all builtin source storages and assistants by default.
Since in most cases users will not have satisfied the requirements of all components, we change the default to --ignore-unavailable-components.
Point 2. and 3. is exactly what we already do for docker:
One valid question here is what has changed between now and #180, which asked for roughly the same but was closed. The reasoning was that it is hard to explain how to satisfy the extra requirements, e.g. setting environment variables. With the introduction of --ignore-unavailable-components we are slightly better now by printing some minimal information during startup:
One solution here would be to just preface every startup with the equivalent of ragna check before the API or UI is started. With that the user should have enough information even when they haven't explicitly created the configuration themselves.
Currently one needs to have a config file, e.g.
ragna.toml, to serve Ragna (ragna uiandragna api). Meaning, users will have to either run the interactive wizard to create one (ragna init) or copy and paste an example from our documentation. That is sub-optimal user experience, because extra steps are required (see #180).However, this is only an issue for serving locally. When using docker, we have solved this by providing a default configuration. We do this, because it involves even more steps to be able to use a user created configuration inside a docker container.
We could bring the same UX from the docker image to local deployment as well. Meaning
-c/--configis not supplied.--ignore-unavailable-components.Point 2. and 3. is exactly what we already do for docker:
https://github.com/Quansight/ragna/blob/55f7fc5d3d13f321eebd16d3b0901ab35ac36bc7/ragna-docker.toml#L4-L28
https://github.com/Quansight/ragna/blob/55f7fc5d3d13f321eebd16d3b0901ab35ac36bc7/Dockerfile#L32-L33
One valid question here is what has changed between now and #180, which asked for roughly the same but was closed. The reasoning was that it is hard to explain how to satisfy the extra requirements, e.g. setting environment variables. With the introduction of
--ignore-unavailable-componentswe are slightly better now by printing some minimal information during startup:https://github.com/Quansight/ragna/blob/55f7fc5d3d13f321eebd16d3b0901ab35ac36bc7/ragna/deploy/_api/core.py#L43-L46
One solution here would be to just preface every startup with the equivalent of
ragna checkbefore the API or UI is started. With that the user should have enough information even when they haven't explicitly created the configuration themselves.Thoughts?