[feat] bindings for different languages/runtimes

InfernalAzazel commented 2 years ago

Describe the problem

Python is used in almost every industry, easy to use

When will python be supported as a backend language, I am very much looking forward to that day.

Describe the solution you'd like

python as backend language

Alternatives considered

No response

Additional context

No response

Arkitect-z commented 2 years ago

Can’t wait to use python machine learning on Tauri !

link89 commented 2 years ago

I am wondering if nanomsg can be used as a message bus between wry and Python process or thread. Theoretically this method could be language agnostic.

ghost commented 2 years ago

yes python coders literally need this kind of stuff

InfernalAzazel commented 2 years ago

There was a problem with the translation last time, I've been following for 104 days I'm waiting to support python Come in every once in a while to see the progress I don't know if it can be used in 2023?

FabianLars commented 2 years ago

I don't know if it can be used in 2023?

2023 at the earliest, i wouldn't be surprised if it takes even longer. There was no work done for it yet.

InfernalAzazel commented 1 year ago

Artificial intelligence is very popular now, and I have been looking forward to the arrival of binding Python

mchao123 commented 1 year ago

Hey there! I was wondering if it would be possible to add TypeScript/JavaScript as supported backend development languages. A lot of us Electron users would really appreciate this feature. It would be awesome if we could choose to use either Bun.js, Deno, or Node.js as the runtime. It can be quite challenging for frontend developers to switch to other languages, so having this option would be a game-changer. I understand that it's a big ask, but I think it would make a lot of us really happy. Thank you for considering this request.

mchao123 commented 1 year ago

Here's a suggestion to share with Tauri developers: Consider leveraging Rust to provide APIs for other backend languages. For example, you can bind Node.js and provide IPC communication APIs and window objects. The remaining tasks such as file I/O and network requests can be handled by Node.js. This way, future development teams only need to update and maintain the IPC and window APIs.

JonasKruckenberg commented 1 year ago

This is something we're incredibly excited and eager to implement and it's something we have had on our roadmap (https://tauri.app underneath the features section) for ever. However, it is a monstrous, herculean effort to actually pull of. Each language has its own concepts, primitives and idiomatic ways of doing things and we're already stretched thin as-is. However, we have made changes in Tauri and will continue to do so that will make it easier to implement proper bindings to Tauri's components in other languages so bear with us.

mildred commented 1 year ago

Probably this needs to be implemented by someone from the language community. Do you have directions on how to start implementing this? Do we have some functions callable from C / FFI that could be used?

Zireael07 commented 8 months ago

2023 has come and gone and it seems this isn't happening?

InfernalAzazel commented 7 months ago

Now tauri has achieved linux windows mac iOS/iPadOS Android which is a great feat. It is planned to bind the python backend and put it on the agenda.

I hope I can use it in 2024！

mildred commented 4 months ago

From the Tauri side, there is just the need of a foreign function interface. Some extern C functions that could be called using FFI or any other means from any programming language. It doesn't even need to cover the full API, just the minimum subset required to run Tauri from a foreign language.

InfernalAzazel commented 4 months ago

From the Tauri side, there is just the need of a foreign function interface. Some extern C functions that could be called using FFI or any other means from any programming language. It doesn't even need to cover the full API, just the minimum subset required to run Tauri from a foreign language.

I am not familiar with Rust, do you have any examples as a guide? Perhaps this is a research direction that can be given a try.

InfernalAzazel commented 4 months ago

From the Tauri side, there is just the need of a foreign function interface. Some extern C functions that could be called using FFI or any other means from any programming language. It doesn't even need to cover the full API, just the minimum subset required to run Tauri from a foreign language.

This is what ChatGPT told me

Sure, here's how you can create a minimal FFI (Foreign Function Interface) to call Tauri functions from another programming language (like C or Python).

1. Create a Tauri Rust Project

First, ensure you have Rust and the Tauri CLI installed. Then create a new Tauri project:

cargo install tauri-cli
tauri init

2. Add FFI Support

In your Cargo.toml file, add the required dependencies and configure the crate type:

[dependencies]
tauri = { version = "1.0", features = ["api-all"] }
libc = "0.2"  # For interoperability with C

[lib]
crate-type = ["cdylib"]

3. Implement FFI Interface

In src/main.rs, implement the functions you want to expose via FFI:

extern crate libc;
use libc::c_char;
use std::ffi::CString;
use std::os::raw::c_void;

#[no_mangle]
pub extern "C" fn start_tauri_app() {
    tauri::Builder::default()
        .run(tauri::generate_context!())
        .expect("error while running tauri application");
}

#[no_mangle]
pub extern "C" fn get_greeting() -> *const c_char {
    let greeting = CString::new("Hello from Tauri!").unwrap();
    greeting.into_raw()
}

#[no_mangle]
pub extern "C" fn free_string(s: *mut c_char) {
    if s.is_null() { return; }
    unsafe {
        CString::from_raw(s);
    }
}

4. Compile as a Dynamic Library

Compile your project as a dynamic library:

cargo build --release

This will generate a dynamic library file in the target/release directory, such as libyour_project_name.so (on Linux) or libyour_project_name.dylib (on macOS), and your_project_name.dll (on Windows).

5. Call Rust Functions from Other Languages

Using C to Call Rust Functions

Create a simple C program to call the Rust functions:

#include <stdio.h>
#include <stdlib.h>

extern void start_tauri_app();
extern char* get_greeting();
extern void free_string(char*);

int main() {
    start_tauri_app();

    char* greeting = get_greeting();
    printf("%s\n", greeting);
    free_string(greeting);

    return 0;
}

Compile and run the C program:

gcc -o tauri_app main.c -L. -lyour_project_name
./tauri_app

Using Python to Call Rust Functions

You can use ctypes or cffi in Python to call Rust functions. Below is an example using ctypes:

import ctypes

# Load the dynamic library
lib = ctypes.CDLL('./target/release/libyour_project_name.so')

# Define the function prototypes
lib.start_tauri_app.restype = None
lib.get_greeting.restype = ctypes.c_char_p
lib.free_string.argtypes = [ctypes.c_char_p]
lib.free_string.restype = None

# Call the functions
lib.start_tauri_app()

greeting = lib.get_greeting()
print(greeting.decode('utf-8'))
lib.free_string(greeting)

Summary

By following these steps, you can expose Tauri's functionality to other programming languages via FFI. The steps include:

Creating a Tauri project and adding FFI support.
Implementing functions to be exposed to other languages.
Compiling the project as a dynamic library.
Using another programming language to load and call these functions.

This approach enables interoperability between Tauri (Rust) and other programming languages, allowing you to leverage Tauri's capabilities in a cross-language environment.

thewh1teagle commented 4 months ago

Hey everyone Based on @InfernalAzazel great answer I created C-API library for Tauri with Python bindings. It uses Tauri API's directly. direct C like calls. https://github.com/thewh1teagle/tauric

InfernalAzazel commented 2 months ago

Hey everyone Based on @InfernalAzazel great answer I created C-API library for Tauri with Python bindings. It uses Tauri API's directly. direct C like calls. https://github.com/thewh1teagle/tauric

I’m looking forward to coming over in 2 years to see the details.

If you use the C-API library for Tauri, there will be a problem. Translating the Tauri plug-in into C-API is a huge workload and depends on a specific version. It cannot keep up with official bug fixes or patches, and each maintenance is huge.

I'm wondering if it's possible to embed rust, or to be able to translate it easily in the middle

Or use c-api. The official library has a standard library for writing plug-ins. This library allows the author of the development plug-in to easily compile c-api, thus forming a unified tool chain.

C-API library for Tauri, Summary：

When the official release of tauri is packaged, it is translated into c-api.
There needs to be a library or CIL that can standardize plug-in development. Authors who develop plug-ins also generate c-api when publishing and using it.
Do the above two things well and leave the rest to community developers

WSH032 commented 1 month ago

Hi Community, for those looking for Python bindings, I am developing ergonomic and maintainable bindings for Tauri using Pyo3:

PyTauri

I plan to support all official Tauri plugins. Although it's far from production-ready, a demo is already available:

Code: https://github.com/WSH032/pytauri/tree/8a4fc2e3d8a8e60a8ffbfbf0d7a0af0338fea542/example

Python

from pydantic import BaseModel
from pytauri import py_invoke_handler, AppHandle
from pytauri_plugin_notification import NotificationExt

class Person(BaseModel):
    name: str

class Greeting(BaseModel):
    message: str

@py_invoke_handler()
def greet(person: Person, app_handle: AppHandle) -> Greeting:
    notification_ext = NotificationExt(app_handle)
    notification = notification_ext.notification()
    notification.builder().title("Greeting").body(f"Hello, {person.name}!").show()

    return Greeting(message=f"Hello, {person.name}!")

Frontend

import { pyInvoke, fromJson } from "tauri-plugin-pytauri-api";

export interface Person {
    name: string;
}

export interface Greeting {
    message: string;
}

export async function greet(person: Person): Promise<Greeting> {
    const response = await pyInvoke("greet", person);
    return fromJson(response);
}

Demo

python -m pytauri_demo

Challenges

For Python developers, although writing Rust code is not required, a Rust compiler is still needed (not for users).

This is because Tauri relies on tauri.config.json and generate_context! for compile-time configuration. Therefore, we cannot provide precompiled python wheel (i.e., no runtime configuration).
Additionally, the regular Tauri development process heavily relies on Tauri-Cli to generate executables. However, for Pyo3 bindings, dynamic libraries (.so/.dll/.dylib) are required, so we cannot use Tauri-Cli and must use cargo build instead.

I hope Tauri can document the behavior of Tauri-Cli and provide documentation on using cargo build as an alternative. There was an example of using Tauri as a dynamic library, but it has been removed for some reason? @amrbashir, Can I know why?
Unable to use Tauri's bundler and updater. Specifically, we can generate executables using PyInstaller, but we currently cannot use Tauri-Cli to package it because the executable path packaged by Tauri-Cli is hardcoded.

In short, Tauri and Tauri-Cli are too tightly coupled. PyTauri needs more collaboration with the Tauri project to be more ergonomic.

Development Plan

You can view PyTauri's development plan here: Pytauri Philosophy.

I hope to integrate with nicegui for full-stack Python GUI development in the future.

Probably this needs to be implemented by someone from the language community.

As @mildred said, a binding requires community effort. I hope someone from the community can participate in the development of PyTauri. Without community contributions or funding incentives, it is difficult for personal projects to sustain.

amrbashir commented 1 month ago

For Python developers, although writing Rust code is not required, a Rust compiler is still needed (not for users). This is because Tauri relies on tauri.config.json and generate_context! for compile-time configuration. Therefore, we cannot provide precompiled python wheel (i.e., no runtime configuration).

You can skip calling tauri::generate_context! macro and code your own context creation based on a runtime configuration object.

Additionally, the regular Tauri development process heavily relies on Tauri-Cli to generate executables. However, for Pyo3 bindings, dynamic libraries (.so/.dll/.dylib) are required, so we cannot use Tauri-Cli and must use cargo build instead.

This is expected because tauri-cli streamlines the development process of tauri applications, dynamic libraries is not in scope for the CLI. There is a few things that tauri-cli does, which can't be done automatically with cargo build, see https://github.com/tauri-apps/tauri/pull/11098 for an effort to reduce the gap between cargo build and tauri-cli.

I hope Tauri can document the behavior of Tauri-Cli and provide documentation on using cargo build as an alternative.

That we can do, probably best to open an issue in https://github.com/tauri-apps/tauri-docs

There was an example of using Tauri as a dynamic library, but it has been removed for some reason? @amrbashir, Can I know why?

It wasn't doing what you think it might be doing. It just compiled a tauri app as dynamic library with a single entry point, and then it was ran inside a cpp application, you can't access any tauri API or provide a different configuration. It's something that can be done with any Rust project really, not specific to tauri.

Unable to use Tauri's bundler and updater. Specifically, we can generate executables using PyInstaller, but we currently cannot use Tauri-Cli to package it because the executable path packaged by Tauri-Cli is hardcoded.

There is cargo-packager which is an effort by CrabNebula to extract the tauri-bundler in a separate project that works for Rust projects, JS and virtually any ecosystem. Tauri might use this under the hood in the future.

In short, Tauri and Tauri-Cli are too tightly coupled. PyTauri needs more collaboration with the Tauri project to be more ergonomic.

We are happy to provide help where we can but we are small number of developers and a bit stretched across the project.

tauri-apps / tauri