@cguedes @sehyod Can y'all take a look at the video above and front-end changes in this PR? Do we need to change something about how interactWithAi with fires now? So that we aren't firing this command too quickly and getting out of order results?

Nice!

I was imagining a world where we ship the binary as a sidecar but the shared libraries as resources. With this approach do we lose Tauri’s process supervision? In other words do we need to clean up the resources used by our Python process such as sockets, and do we need to monitor and restart it ourselves if it fails?

Also I agree we should not fire AI interactions on select, we should have a way for the user to trigger the interactions either in the editor or the sidebar or both.

With this approach do we lose Tauri’s process supervision? In other words do we need to clean up the resources used by our Python process such as sockets, and do we need to monitor and restart it ourselves if it fails?

I don't believe so since we're ultimately still using the same command api, but agree we should get some clarity on the tradeoffs between this approach and the sidecar.

Answers from the Tauri team on my questions above:

Do we have to include the target-triple in the filepath? How do we bundle resources for other OS using this pattern? I was only able to get this working by specifying the full path, including the target-triple.

yes and no? Kinda depends on the build pipeline, if building the python app is part of CI and won't be checked into git then you can just use the same folder on all platforms probably. If not, or if there are platform specific configs/changes however that could look like then you probably need a similar approach.
Btw there are platform specific tauri config files you can use to have the same cmd on all platforms using different folders: https://tauri.app/v1/api/config#platform-specific-configuration

Since we are all using Macs and not checking in the binary, we will likely need CI/CD to build it for us anyway. So in this case, we shouldn't have to worry about the target-triple and should be able to have the following cmd path in tauri.conf for all OS:

        {
          "name": "ingest-pdfs",
          "cmd": "$RESOURCE/bin/python/main/main",
          "args": true
        }

Does using the binary as a resource vs a sidecar change anything about how we have to manage the underlying processes? Do we need to clean up the resources used by our Python process such as sockets, and do we need to monitor and restart it ourselves if it fails?

a very valid question! But there is no difference in the behavior/cleanup as long as you use tauri's Command/Child apis
That said, i still suggest having a close eye on the cleanup because tauri only kills the main sidecar process but doesn't touch its children. For most of the sidecars i've seen so far this wasn't a problem, but for pyinstaller in single file mode it actually was, because it uses a wrapper process which doesn't notify the child, nor does the child check if the parent still exists...

In that case i tend to recommend https://docs.rs/command-group/latest/command_group/ with which you'll have to do the cleanup yourself but at least all sidecar processes should be killed. iirc this wasn't necessary for pyinstaller's folder mode but i didn't see it in use with sidecars that big so i'm not 100% sure