Supporting mixed pytauri pyinvoke and tauri rust invoke handlers in a traditional tauri app

[rakataprime]

Hi,

I have recently tried adapting the examples that both launch with python and use pyinvoke handlers almost exclusively and tried do more of a normal tauri app launched by rust not python but mixes and matches pyinvoke and rust invoke and I persistently get alot of errors like 'RuntimeError: py_invoke_handler raised an exception thread 'tauri-plugin-pytauri-gil-rt' panicked at [...]: py_invoke_handler shouldn't raise exception'

I think some of this may be related to launching on python vs rust and gil.

Is this going to be something that will be supported in future ?

[WSH032]

Hi @rakataprime.

It's not a problem with the GIL, but maybe related to the way that you launch via rust.

launched by rust not python but mixes and matches pyinvoke and rust invoke

I'm not sure if I understand what you mean. Can you provide me with some code (or upload it as a repository on GitHub)? Also, if you can provide the full traceback, it will help me locate the issue.

[WSH032]

• commands is not py_invoke_handler, commands.generate_handler(portal) is.
• The API of tauri_plugin_pytauri::init is currently private, you should not use it directly. Why do you want to use App:run in Rust directly instead of using App.run in Python? This might be an XY problem.

[WSH032]

Can you have a try:

from contextlib import ExitStack

from anyio.from_thread import start_blocking_portal
from pytauri import Commands

__all__ = ["invoke_handler"]

commands = Commands()

exit_stack = ExitStack()
portal = exit_stack.enter_context(start_blocking_portal())

invoke_handler = commands.generate_handler(portal)

Disclaimer: I really don't recommend doing this. If you insist on doing it, it's best to call ExitStack.close or ExitStack.__exit__ in Rust to catch/handle errors sent from the Python asynchronous runtime.

[rakataprime]

My motivation for using App.run in Rust directly—as opposed to invoking App.run from Python—is to retain full control of the application lifecycle within the Rust environment, which offers several key benefits: bypassing the GIL, native tauri ecosystem integration,and better bundling / maintainability. My current tauri codebase has a lot of rust and it may be preferable for some developers to do mostly tauri with a few python handlers for certain libraries not handled well in rust.

I discovered that my initial issue was due to mistakenly removing the Tauri handler initialization from lib.rs in tauri_app example unintentionally. Tauri accepts command registration there, so reintroducing the handler registration fixed the “command greet not found” error. This confirms that Tauri’s Rust-side builder and plugin system is functioning as expected when I launch/bundle the app via the Tauri CLI—even without using Python as the primary entrypoint.

I don't know if worth tweaking the documentation / examples readme to show that you dont have to launch the apps exlusively with python -m or to adding a few comments on tauri builder moved to lib.rs and wrapped there. It was my oversight for not seeing where the rust init handler was. In terms of long term direction, I don't have a strong opinion on wrapping the original tauri builder and if this works well now that's good enough for me.

I hope this clarifies my approach. Thanks for your feedback!

[WSH032]

Have you seen this part of the documentation launch-the-app-in-dev-mode? Pytauri can be launched either through python -m or tauri dev.

I forgot to add the tauri dev instructions in the README, which is indeed my oversight (my intention was to guide through the tutorial documentation).

---

I don't know how familiar you are with pyo3, but pytauri exposes Rust APIs through pyo3, and you can fully control it through these APIs.

# use `ExitStack` to avoid exiting the portal contextmanager
exit_stack = ExitStack()
portal = exit_stack.enter_context(start_blocking_portal("asyncio"))

app = builder_factory().build(
    BuilderArgs(
        context=context_factory(),
        invoke_handler=commands.generate_handler(portal),
    )
)

// Get the app: PyObject from above, just like you did with py_invoke_handler:
// https://github.com/rakataprime/pytauri/blob/main/examples/rustandpyinvoke-tauri-app/src-tauri/src/main.rs
use pyo3::prelude::*;
use pytauri::ext_mod::App;

fn run(app: PyObject, py: Python<'_>) -> PyResult<()> {
    let py_app = app.downcast_bound::<App>(py)?;
    let rs_app_ref = py_app.borrow();
    let rs_app = rs_app_ref.0.try_take_inner()??;
    rs_app.run(|_, _| {});
    Ok(())
}

Although the Rust API may not be as stable as the Python API, I will document every public API BREAKING CHANGE.

Additionally, if you want to use these Rust APIs, you might also need to check out pyo3-utils (although its documentation might not be very good).

---

BTW, even if you use the Python API, the underlying Rust calls in pytauri will release the GIL, so you don't have to worry about GIL issues.

[WSH032]

adding a few comments on tauri builder moved to lib.rs and wrapped there. It was my oversight for not seeing where the rust init handler was.

I thought that if users were learning through the tutorial, they would naturally notice this. It turns out I was wrong 😱. Can you create an issue/PR about the DOCS?

---

I don't have a strong opinion on wrapping the original tauri builder

We must do this. In pytauri v0.4, I plan to provide pre-built Python wheels so that pure Python users can completely get rid of the dependency on the Rust compiler.

Of course, we will still provide first-class support for Rust users.

---

I think the only parts you need to control in Rust are Context, Builder, and App/App::run, right?

You should be able to modify pytauri::pymodule_export in lib.rs to solve the first two (I specifically exposed them for Rust developers).

---

It was my oversight for not seeing where the rust init handler was.

So, did you eventually solve your problem? If not, please continue to ask, and I will do my best to help you!