Is your feature request related to a problem? Please describe.
If you want multiple input types, this is a clean way to do it. This currently doesn't work:
@action(...)
def process_input(state: State, input_text: str, input_doc=None: Document=None) -> ...:
...
This is something like what chatGPT does.
Describe the solution you'd like
This should work. It should make sure not to break if its not provided. Currently this will:
- Not parse it as an input: see https://github.com/DAGWorks-Inc/burr/blob/26cfcd272a26c58e88c6ec84b18682b8ad87a9bd/burr/core/action.py#L370
- Then not process it -- meaning it will break silently...
Instead, we should:
- Enable a list of optional inputs
- Break only if all required inputs are present
Should be as easy as adding another + some tests.
Describe alternatives you've considered
This is generally solvable by grouping into an input type that encodes the default relationships:
class UserInput(pydantic.BaseModel):
prompt: Optional[str]
document: Optional[Document]
@action(reads=..., writes=["document", "prompt"])
def prompt(state: State, user_input: UserInput):
...
This has the advantage of being easier to manage/inspect from a single object in the UI. Furthermore, any more complex
relationships can be easily encoded here. That said, it's less ergonomic, and requires some sort of object/dataclass setup.
Additional context
Inspired by user Milan on discord!
Is your feature request related to a problem? Please describe.
If you want multiple input types, this is a clean way to do it. This currently doesn't work:
This is something like what chatGPT does.
Describe the solution you'd like
This should work. It should make sure not to break if its not provided. Currently this will:
Instead, we should:
Should be as easy as adding another + some tests.
Describe alternatives you've considered
This is generally solvable by grouping into an input type that encodes the default relationships:
This has the advantage of being easier to manage/inspect from a single object in the UI. Furthermore, any more complex
relationships can be easily encoded here. That said, it's less ergonomic, and requires some sort of object/dataclass setup.
Additional context
Inspired by user Milan on discord!