This adds `code_executions` as an array of code execution statuses to
chat messages. The intent of this data is to be displayed in a similar
manner as citations: at the bottom of the message, with buttons that open
a modal for more info. However, code execution data doesn't fit well in
citation modals, because they fundamentally differ in their formatting.
Code execution status includes the code that was run (which benefits from
being syntax-highlighted), and the output and generated files. This
differs from citations which are just list of document names and links.
Additionally, code execution is a process, whereas citations are only
emitted once. This is why code execution data uses an ID-based approach,
where each code execution instance is identified by a unique ID and can
be updated by emitting a new `code_execution` message with the same ID.
This allows the code execution status to be updated as code runs.
This fixes "The process cannot access the file
because it is being used by another process"
errors on Windows.
The file is still automatically deleted by the
`os.unlink` call later in the function.
Updates #5606Fixes#5642
Commit cf86ba7786 changed the way toolkits
and functions were imported to use `exec`, whereas they previously were
written to files and `import`ed. The use of `exec` means that
module-global variables such as `__file__` are no longer defined.
This breaks https://github.com/EtiennePerot/open-webui-code-execution
(code execution tool for Open WebUI), as the module needs to re-execute
its own code in a subprocess in order to properly sandbox itself. This
is done using `__file__` in order to know where the module's code is
located.
This PR creates a temporary in-memory file that contains the imported
toolkit or function's code and exists only during the import process.
Then it injects the path to this in-memory file as the `__file__`
variable in the `exec` context. This restores the ability for the
toolkit or function being imported to rely on `__file__`.
Etienne Perot